Make GTG 0.4 → GTG 1.0
Instead of: 0.2.1 → 0.2.2 → 0.3 → 0.3.1 → ...
use: 0.2.1 → 0.2.2 → 1.0 → 1.1 → ...
The initial "0." is pointless. People who discover and use FOSS tools don't usually think, "Oh, the version number is greater than 1.0, it must be rock-solid stable and I will complain loudly if it is not." ... so that would not be a good reason to keep it.
As major changes (backend refactor, multi-backends, etc.) hit, there should be bigger version number jumps. As those things stabilize, the jumps could get smaller. By starting with 0.x.x, eventually this process will result in 0.x.x.x and asymptotically approach 1.0 without ever getting there!
Blueprint information
- Status:
- Not started
- Approver:
- Gtg developers
- Priority:
- Undefined
- Drafter:
- Paul Natsuo Kishimoto
- Direction:
- Needs approval
- Assignee:
- Gtg developers
- Definition:
- Pending Approval
- Series goal:
- Proposed for trunk
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
Related branches
Related bugs
Sprints
Whiteboard
According to http://
2010-02-25 khaeru — that page says "0.3 is the next major version of GTG"...if the first digit doesn't signify *major* versions, what does it mean?
2010-02-25 rousseau — in my view, we should hit the 1.x version when the core features are stable. I think we have some things to fix before that:
- get acceptable performances (Lionel's refactoring is doing that)
- mechanism for other sources of task (backends will provide that, but they should be stabilized)
I guess we'll have stable backends with version 0.4, since 0.3 will be the first release of it. So, I agree with Luca, 0.4 is more like 1.0 for me.
Usually, we create the serie when we are close to a release, so that people do not commit to the wrong branch.
2010-03-01 khaeru — OK, that's fine. I guess to implement, someone could create the 1.0 series to follow 0.3?
