New release policy of trunk

214 views
Skip to first unread message

Christian Boos

unread,
Feb 19, 2012, 5:36:31 PM2/19/12
to trac...@googlegroups.com
Hi list,

It just occurred to me that it would be a good thing to try out a
new release policy. Since a while, we have this awfully long
major release cycle, together with a more frequent minor release
cycle on the -stable branch. This is how it is, we already tried
to make major releases more frequent but apparently this goes
against the natural pace of the project, so this message won't be
a plea for changing this. Quite the contrary, I think that a
somewhat long release cycle has also its advantages, as it gives
time to the plugin ecosystem to mature around new versions and
also gives us enough room to polish the features or the API we
want to maintain in the long term. But of course the disadvantage
is that a lot of the good work that appears on trunk takes a very
long time to reach the users, at least the vast majority not
comfortable with the idea of using the latest commit on trunk of
the day. Making the new cool features also available on -stable
would somehow defeat the very idea of having a -stable branch. It
would put too much at risk the API stability we try to guarantee
to plugin authors, as big new features often come together with
API clean-ups and evolution.

So how to preserve the advantages of this model while at the same
time making the new features more readily available to a greater
number of users? Simple. Make some "checkpoints" on trunk. Long
time readers of this list already now about that old idea of mine
of making "pre"- releases. Those would be well tested, stable
versions which we are confident people could use (no big deal,
that's how we already feel about trunk, at least most of the
time, so this would just help other people "identify" such
times!). What's the difference then we a real release or even a
beta release? A non-binding feature set and API. We won't make
the guarantee that what's in a pre-release will be the same in
the final release, we reserve the right to change our mind. Of
course, from pre-release to pre-release, we'll document what has
changed, in order to make it easier for plugin authors who which
to support these pre-releases. I believe this is worth trying,
now. I'm all for making a 0.13pre1 release by the end of this
month (knowing we're not yet done with 0.13 even for a beta, but
it's nevertheless already good and stable enough to start to get
people using it more broadly).

-- Christian

Remy Blank

unread,
Feb 20, 2012, 4:50:57 AM2/20/12
to trac...@googlegroups.com
I know we have already discussed this, and you have already heard my
arguments, but as the discussion was private, I will still repeat them here.

Christian Boos wrote:
> It just occurred to me that it would be a good thing to try out a
> new release policy. Since a while, we have this awfully long
> major release cycle, together with a more frequent minor release
> cycle on the -stable branch. This is how it is, we already tried
> to make major releases more frequent but apparently this goes
> against the natural pace of the project, so this message won't be
> a plea for changing this.

I agree with the first part, but disagree with the latter: we haven't
really tried to do more frequent major releases. I see two major reasons
that have held this back:

- A lack of time to dedicate to the project.

- Our feeling that a major release must contain something radically new
/ improved / shiny / (insert your pet characteristic here), and
therefore our unwillingness to "let go" of something that we think is
only an incremental improvement.

I have hopes that our new team members will help with the former. But
the latter is only a question of mindset, and nothing prevents us from
changing it today.

I understand the argument that API changes must have some kind of
"incubation phase" for plugin maintainers to catch up, but I'm not sure
this is actually how it works. Isn't it rather that plugin maintainers
don't do anything until their plugin breaks, which only happens when
their users start using the new major version? And this in turn only
starts happening when we actually release the new version (except for
those few users living on the edge).

(I fully expect Simon to jump on this one ;)

> So how to preserve the advantages of this model while at the same
> time making the new features more readily available to a greater
> number of users? Simple. Make some "checkpoints" on trunk. Long
> time readers of this list already now about that old idea of mine
> of making "pre"- releases. Those would be well tested, stable
> versions which we are confident people could use (no big deal,
> that's how we already feel about trunk, at least most of the
> time, so this would just help other people "identify" such
> times!).

If the -pre releases are already well-tested and stable, why not just
call them "major" releases? The "non-binding feature set and API"
doesn't hold, as we don't guarantee that between major releases either.

Frankly, I don't think that making our release process more complex (by
introducing one more type of release) is going to be any help. If
anything, we should rather try and make it simpler.

> I'm all for making a 0.13pre1 release by the end of this
> month (knowing we're not yet done with 0.13 even for a beta, but
> it's nevertheless already good and stable enough to start to get
> people using it more broadly).

I'd actually be all for making a 0.13b1 release by the end of this month :)

Here's my counter-proposal:

- One minor release every 3 months, or as needed (e.g. security fixes,
blockers).
- One major release every 6 months.
- The ~2 weeks prior to each release are used to stabilize the code.
Unfinished code is either completed or reverted (the latter case should
be infrequent: very experimental features should be implemented in a
Mercurial or git branch).
- When a release deadline arrives, we release what we have. Whether we
have 1 or 10 or 100 new features and fixes is irrelevant. The goal is to
get the code out to our users.

Time intervals could be adapted, but I wouldn't make them much longer
than that. I find it depressing enough to think that a cool new feature
will have no users for 6 months (and 21 months already in the case of 0.13).

-- Remy

signature.asc

Christian Boos

unread,
Feb 20, 2012, 5:21:44 AM2/20/12
to trac...@googlegroups.com
On 2/20/2012 10:50 AM, Remy Blank wrote:
> - Our feeling that a major release must contain something radically new
> / improved / shiny / (insert your pet characteristic here), and
> therefore our unwillingness to "let go" of something that we think is
> only an incremental improvement.

Very true... "Worth a major upgrade and risk to break existing plugins"
would be my pet characteristic :-)


> Frankly, I don't think that making our release process more complex (by
> introducing one more type of release) is going to be any help. If
> anything, we should rather try and make it simpler.

Well, those pre-releases would allow us to keep only two lines of
development (-stable and trunk), so it's not really more complex or
changing our habits, whereas:

> Here's my counter-proposal:
>
> - One minor release every 3 months, or as needed (e.g. security fixes,
> blockers).
> - One major release every 6 months.

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? If not, then I'm also very much willing to try
this alternative.

-- Christian

Remy Blank

unread,
Feb 20, 2012, 11:00:54 AM2/20/12
to trac...@googlegroups.com
Christian Boos wrote:
> Very true... "Worth a major upgrade and risk to break existing plugins"
> would be my pet characteristic :-)

Right, upgrading to the next major release does have an associated risk.
And it's not completely trivial to install two major versions of Trac in
parallel, to test the upgrade prior to upgrading the live site (at least
one version must be installed in a virtualenv, and IIRC it may interact
badly with a globally-installed version, which makes life more difficult
for people who installed through their package manager). Could we
improve this?

> 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.

This is probably a matter of personal preference, and how much effort
each of the developers is willing to invest into supporting older
branches. I'm sure Simon would want us to support older stable branches.
Personally, I have close to no interest in more than one stable branch.

Could we let those people who have an interest in older *-stable
branches maintain them (including commit rights)? A stable branch would
be supported as long as it has a dedicated maintainer.

Note that I don't really have strong feelings about our release process,
so if you want to try the -pre releases for some time, that's fine by me.

-- Remy

signature.asc

Peter Suter

unread,
Feb 20, 2012, 1:03:23 PM2/20/12
to trac...@googlegroups.com
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.

--
Peter

[1] https://wiki.ubuntu.com/LTS

Christian Boos

unread,
Feb 22, 2012, 10:03:18 AM2/22/12
to trac...@googlegroups.com


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

Peter Suter

unread,
Feb 22, 2012, 4:29:23 PM2/22/12
to trac...@googlegroups.com
On 22.02.2012 16:03, Christian Boos wrote:
> 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...).

If releases are time based it would be predictable. Maybe not flexible
enough? I'm not quite sure why this is a problem.

> So to summarize, here are the options as I see it:
> 1) Ubuntu-like:

Firefox [2] is now planning something similar with ESRs (Extended
Support Releases). (Random other examples: [3] [4] [5]). Python [6][7]
is lively discussing a similar proposal.

> 2) Linux < 2.6 style:

I find that confusing for people not already familiar with it. But maybe
that's just me.

In our case it also seems confusing to people that already knew previous
Trac versions and will naturally assume versions >=0.13 mean similar
things as versions <=0.12.

> 3) A variant of the above: when 0.99.y is deemed stable it becomes 1.0

A bit better than 2). The major change might cause people to look a bit
closer and notice the new meaning of uneven "unstable" releases.

> 4) Another variant: when 0.13.0.y is deemed stable it becomes 0.13.1

I could easily see someone packaging 0.13.1, 1.1 or 0.13.0.1 without
noticing it's not supposed to be LTS/stable. So an explicit "preZ" label
seems better to me.

(Or no change and just do more releases. If there's a lot of demand /
volunteers consider minor updates for older branches with back-ported
bug-fixes.)

> 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!

Instead of labeling the LTS releases, one could label the non-LTS
releases. Sounds similar to "preZ" labels again.

Some alternative label terms (from [8]): preview, prototype, technical
preview (TP), early access or community technology preview (CTP) (Maybe
sounds too much like Microsoft :))

--
Peter

PS: I personally liked the idea to go to 13.0 instead of 0.13 or 1.0.

[2] http://www.mozilla.org/en-US/firefox/organizations/
[3] https://wiki.jenkins-ci.org/display/JENKINS/LTS+Release+Line
[4]
http://www.joomlablogger.net/blog/joomla-news/understanding-the-joomla-release-cycle/
[5] http://blogs.digium.com/2012/02/14/asterisk-lts-every-2-years/
[6] http://www.python.org/dev/peps/pep-0407/
[7] http://mail.python.org/pipermail/python-dev/2012-January/115573.html
[8] http://en.wikipedia.org/wiki/Software_release_life_cycle

Remy Blank

unread,
Feb 22, 2012, 4:34:16 PM2/22/12
to trac...@googlegroups.com
Christian Boos wrote:
> 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 (...)

That actually sounds pretty good. Having an explicit "LTS" marker
(instead of relying on people knowing that odd versions are unstable) is
a good thing.

> 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" (...)

That sounds even better. Except that I would drop the 0.99 and just make
0.13 become 1.0 instead. Who said you had to count to 0.99 before going
to 1.0?

> 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...

Yep, me too.

> 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" (...)

So there's already a whole version component that we don't use, and you
want to add another one? You can't be serious ;)

> 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...

Big +1 for 1.0.

-- Remy

signature.asc

Christian Boos

unread,
Mar 2, 2012, 5:44:16 PM3/2/12
to trac...@googlegroups.com
To hopefully conclude with this thread...

I just stumbled upon the recent release history of NGINX,
and that's very close to what I'd like to see in Trac:

2012-02-29 nginx-1.1.16 development version has been released.
2012-02-15 nginx-1.1.15 development version has been released.
2012-02-06 nginx-1.0.12 stable version has been released.
2012-01-30 nginx-1.1.14 development version has been released.
2012-01-16 nginx-1.1.13 development version has been released.
2011-12-26 nginx-1.1.12 development version has been released,
introducing cache lock support and PCRE JIT support.
2011-12-15 nginx-1.0.11 stable version has been released.
2011-12-12 nginx-1.1.11 development version has been released.
2011-11-30 nginx-1.1.10 development version has been released.
2011-11-28 nginx-1.1.9 development version has been released.

(as seen on http://nginx.org)

i.e two 1.0.y minor stable versions released, interspersed in the
release of many 1.1.y minor development versions.


On 2/22/2012 10:34 PM, Remy Blank wrote:
> Christian Boos wrote:
>> 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 (...)
>
> That actually sounds pretty good. Having an explicit "LTS" marker
> (instead of relying on people knowing that odd versions are unstable) is
> a good thing.

Or like in the nginx case, just an explicit "stable version" label.
"Long Term Support" could be more appropriate for the few stable
releases we really would like to support for a very long time, at least
for the security fixes (and 0.12 sounds like a good candidate for such a
LTS label).


>> 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" (...)
>
> That sounds even better. Except that I would drop the 0.99 and just make
> 0.13 become 1.0 instead. Who said you had to count to 0.99 before going
> to 1.0?

Sure, forget the 0.99 thing.

>
>> 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...
>
> Yep, me too.

Sounds good ;-)

So if everyone is OK with transitioning to that model, we could do it
this way:
- 0.13dev becomes 1.0.0dev
- we create a few betas 1.0.0beta{1,2} (more or less the polished
status of what we have now in 0.13dev)
- in parallel we can release 0.12.4 and mark 0.12 as a "LTS" release
- we release 1.0

This 1.0 gives us a good starting point for the new model:
- 1.0.x stable version - gets the bug fixes and gets released regularly
- 1.1.x development version - gets the new features and gets released
as often as we feel like we're ready to give the new stuff a greater
exposure

As usual, every fix from stable also gets merged to development.

Once we feel the 1.1.x development cycle has stalled, diverged too much
from 1.0.x, or it's just time to make a new stable release, we start the
next cycle: 1.2.x stable / 1.3.x development. And eventually either 1.0
or 1.2 will become the next LTS release...

The big difference here with "business as usual", besides the magical
"1.0", is that we'll make the 1.1.x releases early and often.

>
>> 4) Another variant:
>> (...)


>
> Big +1 for 1.0.
>
> -- Remy
>

Yes, besides the fact it's about time for a "1.0", upgrading to that
number will also help people to notice the new release policy.

-- Christian

Remy Blank

unread,
Mar 2, 2012, 11:25:32 PM3/2/12
to trac...@googlegroups.com
Christian Boos wrote:
> So if everyone is OK with transitioning to that model, we could do it
> this way:

Go for it ;)

-- Remy

signature.asc

Peter Suter

unread,
Mar 3, 2012, 2:51:44 AM3/3/12
to trac...@googlegroups.com
On 02.03.2012 23:44, Christian Boos wrote:
> So if everyone is OK with transitioning to that model, we could do it
> this way:

+1

--
Peter

Ed - 0x1b, Inc.

unread,
Mar 3, 2012, 6:50:06 PM3/3/12
to trac...@googlegroups.com
pardon the late entry - I have found the OpenBSD fixed cycle a good
way to eliminate feature driven release arguments - and it is a lot
easier to manage from the users perspective.
http://www.youtube.com/watch?v=i7pkyDUX5uM

> --
> You received this message because you are subscribed to the Google Groups
> "Trac Development" group.
> To post to this group, send email to trac...@googlegroups.com.
> To unsubscribe from this group, send email to
> trac-dev+u...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/trac-dev?hl=en.
>

Peter Suter

unread,
Mar 4, 2012, 3:27:57 AM3/4/12
to trac...@googlegroups.com
On 04.03.2012 00:50, Ed - 0x1b, Inc. wrote:
> pardon the late entry - I have found the OpenBSD fixed cycle a good
> way to eliminate feature driven release arguments - and it is a lot
> easier to manage from the users perspective.
> http://www.youtube.com/watch?v=i7pkyDUX5uM

Interesting talk, but I'm not quite sure how we can apply it to Trac.
Did you have a specific point in mind?

Slides:
http://www.openbsd.org/papers/asiabsdcon2009-release_engineering/

Summary:
* Maximize testing, minimize time lost to release process
* Don't split team in developers and release engineers
* Freeze development until release is done
* Freeze is an unannounced surprise
* Force developers to do testing, punish slackers with commit-bans
* Do daily builds, don't accept broken builds
* Mock people that break builds
* Dog food daily builds in day to day development
* Do a release after exactly 6 months to the day

I guess you mainly referred to that last point?

--
Peter

Eduard-Cristian Stefan

unread,
Mar 4, 2012, 5:54:34 AM3/4/12
to trac...@googlegroups.com, Peter Suter
On 2012-03-04 10:27, Peter Suter wrote:
> Summary:
> * Maximize testing, minimize time lost to release process
> * Don't split team in developers and release engineers
> * Freeze development until release is done
> * Freeze is an unannounced surprise
> * Force developers to do testing, punish slackers with commit-bans
> * Do daily builds, don't accept broken builds
> * Mock people that break builds
> * Dog food daily builds in day to day development
> * Do a release after exactly 6 months to the day
>
> I guess you mainly referred to that last point?

I would propose something like Mercurial's release plan:

http://mercurial.selenic.com/wiki/TimeBasedReleasePlan

A release interval of 3 months will make the life easier
for corporate users, since snapshots/dev builds
are not always approved in that kind of environments.

Have a nice day,
Eduard

Eduard-Cristian Stefan

unread,
Mar 4, 2012, 6:49:04 AM3/4/12
to trac...@googlegroups.com
IMHO, something like the Mercurial's crew repo
is required, I have seen a lot of tickets
with patches attached and not applied for months/years.

http://mercurial.selenic.com/wiki/DeveloperRepos

Also, this "crew" repo would be nice to be a Mercurial one,
since SVN is kind of obsolete, and Mercurial have
a better support for Windows developers than Git.

Reply all
Reply to author
Forward
0 new messages