On 2/20/2012 7:03 PM, Peter Suter wrote:
On 20.02.2012 17:00, Remy Blank wrote:
Christian Boos wrote:
In this case, how do you see the relationships between minor and major
releases? Won't we end up with either having a very short maintenance
period for a given major release or having more development branches to
maintain concurrently?
Ah, long-term support, always a tricky issue ;)
I had imagined keeping the same "policy": bug fixes on latest *-stable,
enhancements, features on trunk, and possibly critical fixes on older
*-stable. But I see your point: this would reduce our support to only
versions between 6 and 12 months old. Or we would have to actively
support more *-stable branches.
Some projects (e.g. [1]) "solve" this by marking certain releases for
Long Term Support. For example (tweak numbers as you see fit) we could
release one LTS release every 12 months, one major non-LTS release every
6 months and minor releases every 3 months or whenever needed. Only the
latest LTS release would get a maintained *-stable branch with minor
releases.
This way you can keep the number of maintained branches under control,
make more major releases, and provide relatively long term support. But
of course it's still a quite difficult trade-off.
Interesting idea, but I'm not sure this will make the overall
picture easier to grasp, as we would need to add such a "LTS"
label or similar (mention it in the release? how do we decide
that a particular major release will become a LTS one?).
I think we can all agree on the following goals:
- don't make it more complex than it already is, both for the
users (i.e. make it obvious what is what), and for us (i.e. no
more than two lines of development, 0.X-stable for bug fixes,
trunk for features, roughly put)
- make more frequent releases (3 months for stable, 6 months or
even less for trunk), or even more frequently if it need to be
(- avoid seeing Trac releases with no long term support packaged
in distributions)
So if we keep making major releases following a 0.X++ pattern on
trunk and minor releases on stable (0.X.y++) at the proposed
pace, the only way to not have more than two lines of development
is indeed to not make minor releases for some major
releases. Only a few major releases become "LTS" ones (they get
minor releases), while the others won't and the way to get
upgrade or fixes for the latter ones will be to upgrade to
the "next" major release.
What I fear with that scheme is the lack of predictability (what
will the next LTS release be? 0.14, 0.15?), or have this
predictability at the expense of flexibility (don't release yet
0.14, as we said it will become the next LTS release...).
I would really prefer finding a version numbering scheme which is
at the same time predictable and flexible. For simplicity, it
would be great if we could just keep our current mapping between
lines of development (trunk for version 0.X, and obviously
0.(X-1)-stable for version 0.(X-1)). In that case, the minor
releases on stable would remain numbered 0.(X-1).y. The only new
thing we would need is a version numbering scheme for
those "non-LTS ''major'' releases", and for that there are
several alternatives.
So to summarize, here are the options as I see it:
1) Ubuntu-like:
- 0.12 LTS, with 0.12.{1,2,3,4,...}
- 0.13
- 0.14
- 0.15 LTS (...)
2) Linux < 2.6 style:
- 0.12 LTS, with 0.12.{1,2,3,4,...}
- 0.13 "unstable", with 0.13.{1,2,3,...}
when 0.13.y is deemed stable it becomes 0.14
- 0.14 LTS (...)
3) A variant of the above:
- 0.12 LTS, with 0.12.{1,2,3,4,...}
- 0.99 "unstable", with 0.99.{1,2,3,...}
when 0.99.y is deemed stable it becomes 1.0
- 1.0 LTS, with 1.0.{1,2,3,4,...}
- 1.1 "unstable" (...)
I also think it's about time we go "1.0" but last time I
brought up that topic, a majority of people still didn't feel
like it was appropriate, so it's probably still just me...
4) Another variant:
- 0.12 LTS, with 0.12.{1,2,3,4,...}
- 0.13 "unstable", with 0.13.0.{1,2,3,...}
when 0.13.0.y is deemed stable it becomes 0.13.1
- 0.13 LTS, with 0.13.{1,2,3,4,...}
- 0.14 "unstable" (...)
Yeah right, those 0.13.0.1, 0.13.0.2 releases are my
0.13pre1, 0.13pre2 releases in disguise ;-)
I'm not so fond with 1) as you have only one "dimension" to
express the expected lifetime, hence we'll need some kind of
external labelling to mark one given 0.X as being "LTS". I'm sure
at least one packager or the other will end up picking a non-LTS
version and then will get stuck with it!
I like 2) (call me nostalgic), and it would be even better to go
with 3) but no big deal if people are still averse about a 1.0...
Note that the risk of having a packager picking an "unstable"
series is not nil either, but at least they would take our
next "unstable" releases, which is a bit better.
4) is close to what I had originally in mind, really seeing
those "feature releases" as not much more than episodic "nightly
builds" (i.e. not done automatically every day but each time we
feel like trunk is in a good state). Rémy's concern was that
these checkpoint releases would sooner or later be comparable to
real major releases, in which case using the "preZ" labels (or
here the micro 0.X.0.Z) numbers would not be appropriate. Btw,
using "betaZ" labels instead is not that nice either, as "beta"
usually imply we're close to some final release and that it won't
change much until then, which wouldn't be the case
here. Using "m1" (for "milestone 1") would be fine, except that
in Trac the "Milestone" term is already closely associated to a
specific minor or major release. Note that except maybe for the
0.X.0.Z numbering, it's unlikely that such labelled releases
might get picked for inclusion in a distribution, which is good.
-- Christian
--
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.
