Home/ Questions/Q 3992406
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-20T06:45:40+00:00

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

  • 0

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

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0