On Wed, Sep 24, 2008 at 4:45 PM, Alex Rousskov <[EMAIL PROTECTED]> wrote: > On Wed, 2008-09-24 at 12:21 +0200, Henrik Nordstrom wrote: >> On tis, 2008-09-23 at 23:30 -0600, Alex Rousskov wrote:
> The DEVEL label is not needed indeed, but I was talking about code > states. I understand now that you use the PRE state for a different > purpose. Please note that your definitions of DEVEL and PRE differ from > the ones on the web site. > > The most annoying thing, IMO, is that the official and your definitions > above have two fuzzy lines for DEVEL and PRE states: stability and > features. One fuzzy line is tolerable, but two make things really > confusing. > >> > > The non-major but important bugs can be fixed during DEVEL and PRE >> > > cycles. Branching is about features not bugs. >> > >> > Agreed, except I do not think we should have any known important bugs >> > when doing the first PRE (if we do PRE at all). >> >> Yes. It's not much use in releaseing a PRE with known major blockers. > > But your definition above says we are still hunting down some bugs. It > does not say there are no major bugs left. > > How about this: > > Trunk: Experimental code and new major features are being added. Use > daily snapshots (e.g., HEAD-YYYYMMDD). No label. > > ... time passes, more features are added ... > > Branching point (e.g., 3.1): All major features are in. Use daily > snapshots (e.g., 3.1-YYYYMMDD). No label. > > ... time passes, all known major bugs get fixed ... > > First numbered release (e.g., 3.1.0): All known major bugs fixed. Could > be labeled a "beta" or "development" release if needed. > > ... time passes, more beta releases are made, with fewer bugs ... > > Branch first marked as "stable" (e.g., 3.1.5): The last numbered release > turned out to be stable! > > ... time passes, the stable branch is maintained ... > > Branch marked as "end of life" or "no longer supported". This is a bit like rehashing an old discussion, I'll however give it a shot but not discuss it further. I'm not a particular fan of DEVEL/PRE/RC/STABLE labels. I like your idea about labelling the branching point and keeping timestamps around for the head and post-branching stabilization phase. I don't like much not having a fixed "stable" marker much tho, what I'd do is: - when major bugs are fixed, a .0 release point is taken. After that during the stabilization phase, milestones are marked with an additional numeral (e.g. 3.2.0.5) - when STABLE level is reached, then a .1 release is taken (3.2.1). After that, it's maintainance mode and new releases are marked by incrementing the third numeral (e.g. 3.2.5). Advantages: - it's fully-numeral - it has a fixed "stable" marker (the .1 release). - it doesn't change much the current numbering approach My 2c; I won't waste more of anyone's time (re-re-re-re-re-re)resurrecting this discussion. -- /kinkie
