Suggestion for a smoother release schedule for future versions of Trac

9 views
Skip to first unread message

Christian Boos

unread,
Oct 12, 2009, 7:12:22 AM10/12/09
to Trac Development
Hello again,

This Friday on #trac (freenode IRC), we were discussing the multirepos
merge and more generally the 0.12 schedule.
I wanted to remind people of some old ideas I sent to the Trac-dev list,
but I couldn't find the reference back then.
Now I have it:

http://groups.google.com/group/trac-dev/msg/4207c000d7c8be9c

The main idea exposed there, in the second part of the mail, was to
create *intermediate releases* during a major development period, once
in a while (e.g. every 3 months) or after some new major feature has
stabilized. Those "pre" releases can be used as reference points
(0.Xpre1, 0.Xpre2, ...), they will help gathering more user and plugin
developer feedback, and they can be used to document more precisely the
API changes (see a detailed example in the mail linked above). A related
idea was that major features could be tracked in topic branches and have
their own (sub)milestone, which is what we finally did for multirepos.

So I'd like to reopen this discussion, as I think the ideas exposed
above are still relevant, but maybe more for 0.13 than for 0.12, which
has seen a "traditional" period of > 1 year of development on trunk with
no intermediate releases and which is now reaching its conclusion anyway
(and the details of it can be discussed in a separate mail - "Tentative
0.12 Release Schedule").

-- Christian

Remy Blank

unread,
Oct 14, 2009, 5:03:04 PM10/14/09
to trac...@googlegroups.com
Christian Boos wrote:
> The main idea exposed there, in the second part of the mail, was to
> create *intermediate releases* during a major development period, once
> in a while (e.g. every 3 months) or after some new major feature has
> stabilized.

Yes, why not? We could try this for a few reference points, and refine
the process (if necessary) as we go along. I assume the idea of "pre"
releases is that they take less work to prepare than normal "major"
releases, and hence provide less stability guarantees.

If we see that "pre" releases save too little effort compared to major
releases, we could still spread them a bit further (6 - 8 months), and
possibly make them full major releases.

-- Remy

signature.asc
Reply all
Reply to author
Forward
0 new messages