On Wednesday 20 Sep 2006 08:00, Heikki Johannes Junes wrote:
> What about starting 1.5.x as a development series?
I have to say that I'm not keen to go for odd/even development/stable release
numbering (although I'm open to argument).
I have no problem with having a stable release branch (as we did for
1.2.3/1.2.4, which despite my misgivings about the long delay between the two
releases turned out pretty well). I could certainly anticipate doing several
releases from the stable branch if we're spending a long time working on new
features elsewhere -- I'd even be happy to see new releases that have no
changes except for updated translations, if appropriate.
I'm far less sure about the development release track. I want it to be
blindingly obvious which release is the latest one that a typical user should
expect to use, and it should be the one with the biggest number on it. The
Rosegarden-2.1/Rosegarden-4 confusion was quite enough confusion for one
Also, while we have multiple developers working on distinct features, I don't
want any of them to feel pressured to reach a cut-off point for a feature
just because there's a development release proposed and they don't want their
half-done work exposed to an undue degree. There are few more irritating
things for a developer who's in the middle of a feature than to have people
start using it "too soon" and complain about things that you're just about to
I especially wouldn't want to see development releases end up in distros -- we
have seen rcX releases that obviously weren't intended to have a long
lifespan end up on distro CDs in the past, and it's quite unhelpful.
Building from SVN is easy (if you can build Rosegarden at all). The hard part
is knowing when something new has appeared that you might want to test. To
that end it might be better to have (semi-?) automated datestamped builds
from SVN, and to post a short note to the -user list when something new has
appeared in one. That way there'd also be less of an expectation that other
features in the same build are "complete".
Also I don't want to get stuck into a rut of only doing unstable releases. We
should have stable, user-ready major releases once a year or thereabouts, but
I can easily envisage a situation where we go over a year only doing unstable
releases and then either get annoyed with bug reports that are "still" only
referring to the last stable release, or get annoyed with bug reports about
the unstable series because it's supposed to be unstable (even though it's
the only current series there is).
Finally, I would like to be able to choose release numbers based on how much
of an advance we feel we've made (like changing 1.3 to 1.4 at the last
minute). I don't want to feel like we have to number our public releases
1.4, 1.6, 1.8, 2.0 etc for the rest of time.
I think Lilypond is actually the only app I use that follows the odd/even
numbering scheme (obviously the other main one, Linux, dropped it a while
back). Lilypond is a very different program to Rosegarden in terms of
development structure, usage style, user expectations etc, and I don't think
there's necessarily much basis for saying if it works for Lilypond that means
it should work for us.
What advantages would you see it having? What do others think? Anyone got
other original suggestions to propose?