On May 3, 2010, at 11:59 PM, Christian Boos wrote: > On 5/4/2010 5:55 AM, Itamar O wrote: >> Hi Christian, >> >> In opensource projects you usually see a 3-level versioning scheme that >> follows the "Major.Minor.Patch" concept. >> According to your detailed description, Trac follows a "shifted" scheme: >> "0.Major.Minor". > > Correct. > >> So I must wonder - what is the purpose of "0." if according to the strategy >> there will never be a "1."? > > Historical reasons, the first public release was 0.5, and at 0.9 we felt we > were too far away of a finished product to feel confident to go with a "1.0", > so that 0.10 was picked and from there the sequence of major releases just > went on. > >> Or differently phrased - what needs to happen in Trac in order to go "1."? > > Think about it differently: what would be the advantage? If we find a role > and a need to use the 1.0 version, then we'll probably use it. But having the > number as a goal in itself, when no real meaning stands behind, is > pointless. Hence the removal of the 1.0 milestone.
Most FOSS projects treat 1.0 as a symbolic gesture of stability. It indicates the developers feel the project is mature and the internals aren't likely to undergo the kind of big changes we still face. The details are naturally project-specific, but you can think of it is that kind of event. Unfortunately Trac isn't at that point in its lifecycle yet, it will get there, but it isn't a specific milestone to plan for as with other releases. --Noah -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
