如何管理源代码的任务和版本?

发布于 2024-10-19 05:42:39 字数 628 浏览 9 评论 0原文

我有一个理论问题:我有一个有版本的项目,例如:

  • 0.1:alpha
  • 1.0:第一个版本
  • 2.0:重大更改

我有一个任务管理系统(Redmine,但对于 trac 或其他任何东西都是一样的...... )。

我应该将将使使应用程序工作的任务放在哪个版本中(目前它不起作用)?是在 0.1 中(一旦 0.1 完成,然后 1.0 工作) 还是在 1.0 中(一旦 1.0 完成,然后 1.0 工作)。

另一种提问方式是:1.0 版本的任务是帮助制作1.0 版本的任务,还是扩展/修复完全可用的1.0 版本的任务。

我很困惑,因为任务可以

  • 先于版本的发布(即正在发布)
  • 跟随版本的发布(即版本已经发布,我们需要修复错误并扩展它)

那么我应该将哪些任务放入版本中?

我不知道如何管理任务和版本,你能帮我吗!它在开源编码中如何工作?

谢谢 !

PS:如果还不够清楚,请告诉我

I have a theoritical question : I have a project that has versions, for example :

  • 0.1 : alpha
  • 1.0 : first release
  • 2.0 : breaking changes

And I have a task management system (Redmine, but it's the same for trac or anything else...).

In which version do I put the task that will make the application work (currently it doesn't work) ? Is that in 0.1 (once 0.1 is finished, then 1.0 works) or is that in 1.0 (once 1.0 is finished, then 1.0 works).

Another way to ask is : Is a task of version 1.0 a task that helps making the 1.0 version, or a task that extends/fixes the fully working 1.0 version.

I am confused, because a task can

  • precede the release of a version (i.e. working on the release)
  • follow the release of a version (i.e. the release is out, we need to fix bugs and extend it)

So which tasks do I put in a version ?

I don't know how to manage tasks and versions, can you help me ! How does it works in Open Source coding ?

Thank you !

PS : please let me know if that is not clear enough

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

离线来电— 2024-10-26 05:42:39

您需要在脑海中区分任务和版本,然后才能返回并应用它们。

任务是您对代码所做的工作。

版本(我在这里集中了所有点版本)是代码的版本。

您在代码上工作、执行任务,目的是发布版本。根据您正在进行的工作范围,该版本可能是完整版本 1.xx、2.xx 等,也可能是单点版本 1.1.x、1.2.x、1.3.x,也可能是次要版本点发布/错误修复/无论你想怎么称呼它,1.0.1、1.0.2、1.0.3。

这些任务可以是错误修复、功能、更改、重构等等。在完整的应用程序开发范围内,您的组织可能将多组任务捆绑到制作下一个版本所需的工作中,或者您可能有发布日期限制,即您将在 2 月 25 日发布版本 2.0.0 2011 年,无论任务已完成(尽管通常必须完成一部分任务才能发布)。

版本发布往往遵循重大更新、升级、功能添加。
点发布往往会进行适度的改进和重大错误修复。
次要版本是错误修复的结果。

无论您转向何处,您都会发现此过程的不同方法,您只需要了解您的公司使用的方法,或者如果有机会,找到一种对您有意义的方法,然后一致地应用它。

You need to separate tasks and versions in your mind before you can come back and apply them.

Tasks are work you do on your code.

Versions (and I'm lumping in all point releases here) are releases of your code.

You to work, tasks, on your code with the objective of making a release. That release, depending on the scope of the work you are doing may be a full version 1.x.x, 2.x.x, etc., or a point release 1.1.x, 1.2.x, 1.3.x or it may be a minor point release/bugfix/whatever you want to call it, 1.0.1, 1.0.2, 1.0.3.

The tasks could be bug fixes, features, changes, refactoring, whatever. In the scope of a full application development you may that your organisation bundles groups of tasks in to the work needed to make the next release or you may have releases date-bound, i.e. you'll release version 2.0.0 on 25-Feb-2011 regardless of the tasks completed (although normally there's a subset that must be complete for the release to happen).

Version releases tend to follow major updates, upgrades, feature additions.
Point releases tend to follow moderate improvements, and major bug fixing.
Minor point releases to be the result of bug fixes.

Every where you turn you will find different approaches to this process and you just need to either understand that used by your company or if you have the opportunity, to find one that makes sense to you and then apply it consistently.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文