On Sat, 23 Jan 2010 14:12:09 +0100 Julien Valroff <[email protected]> wrote:
> > We have a few branches in git: > > > > - MASTER which is the cutting edge, were all commits go > > - and the RELENG branches, which we use to cut the releases from. > > > > You might notice in the commit logs that there is a MFM filed (which > > has a value of N days - the interval that change is supposed to > > stay in MASTER for real-world testing before being merged down in > > RELENG branches). > > MASTER --(maybe)--> RELENG_3 --(maybe)--> RELENG_3_9 --(maybe)--> > > RELENG_3_9_1 > > > > When the release engineering process for a new release is started, > > the RELENG_M_n_u is created. Periodically, things are merged in this > > branch, from which the release will eventually be made. At some > > point (a few days before the first alpha) we declare a feature > > freeze for this branch, and from that point only bug-fixes go in in > > this branch, while development of new things may continue in upper > > branches; for example, there are some new things in RELENG_3_9 and > > RELENG_3_9_1 that were committed to late in 3.9.0 release process > > to make it in 3.9.0. Once 3.9.0 was released, no commit goes in > > RELENG_3_9_0, which is frozen when it was tagged with 3_9_0R. > > > > So if you want to track the thing that will become the next release, > > track RELENG_3_9_1. If you want more, track the upper branches > > (RELENG_3_9 or 3). If you want cutting edge, track MASTER. > > > > Generally, all RELENG_M_m_u branches must compile and run stably, > > RELENG_M_m should, while MASTER may. > > Thanks for your detailed explanations. > I always track master for myself and be sure to adapt the Debian > packages according to the various changes. At the time, I was pretty > sure all the commits made to master would be part of the 3.9.0 > release, which wasn't the case ;) Well, this release has been a bit unusual, because of the long time since the last one, we being a young team, we stayed for long in alpha to rc to release state, etc. At some point one just needs to say stop, this is it, from now we only fix bugs and then release. Generally a micro release will be a drop-in replacement. No config, database, etc. changes will be needed for updating from 3.9.0 to 3.9.1 Small, easy changes are to big expected between minor releases. And big new shiny things for the major ones :) > I now wait that packages for 3.9.0 are more widely tested (as I hope > they can be uploaded to Debian soon!) and will then work again > tracking what will become 3.9.1 so that people can test development > snapshots. It seems we will be ready to cut a beta or even a 3.9.1RC inside a month. -- IOnut - Un^d^dregistered ;) FreeBSD "user" "Intellectual Property" is nowhere near as valuable as "Intellect" FreeBSD committer -> [email protected], PGP Key ID 057E9F8B493A297B
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________ Dspam-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspam-user
