On Thu, Jun 21, 2012 at 02:12:14PM -0300, Cleber Rosa wrote:
> On 06/21/2012 12:30 PM, Ademar de Souza Reis Jr. wrote:
> >On Thu, Jun 21, 2012 at 10:54:12AM -0400, Chris Evich wrote:
> >>On 06/21/2012 10:40 AM, Lucas Meneghel Rodrigues wrote:
> >>>Hi guys,
> >>>
> >>>I ask your suggestions about release management.
> >>>
> >>>One thing that is proving to be a good decision was the creation of the
> >>>'next' branch. We're able to control what's going to 'master' better
> >>>with it. But right now, we have our release tags referencing commits in
> >>>master:
> >>>
> >>>0.14.0 -> commit in master
> >>>0.14.1 -> commit in master
> >>>
> >>>So on and so forth...
> >>>
> >>>Now with Fedora packaging (and possibly other use cases), it is
> >>>necessary that we extend the life cycle of a release, by having release
> >>>based branches, say 0.14, and we would cherry pick fixes from master for
> >>>an extended period of time, so we can release 0.14.2, 0.14.3,... so on
> >>>and so forth.
> >>>
> >>>I'm inclined to go ahead and start doing it, but I'd like to hear your
> >>>opinion about it.
> >>>
> >>>Cheers,
> >>>
> >>>Lucas
<snip>
> >Hello.
> >
> >My understanding is that it should be a branch for each "stable"
> >release. I'm not sure if we have such a policy stablished
> >already, but I would suggest this one:
> >
> >Version format: major.stable.minor
> >
> >- We're at major version 0
> >- The "stable" (for lack of a better term) is 14
> >- The minor (bugfix) is 1
>
> ^ My original question is in much better context here: is a minor
> release supposed to be bugfix only? AFAIK, this has not been the
> case so far.
My understanding is that this is exactly what Fedora guys want
and for sure that's what I'm proposing here.
>
> >
> >So, showing branches + tags:
> >
> >master
> > \
> > |...
> > |----0.13 (branch)
> > | \---- 0.13.0-rc1 (tag)
> > | |---- 0.13.0 (tag)
> > | |---- 0.13.1 ...
> > | |---- 0.13.n
> > |----0.14
> > | \---- 0.14.0-rc1
> > | |---- 0.14.0
> > | |---- 0.14.1
> > | |---- 0.14.2
> > ...
> >
> >We never tag the master branch. Releases would be made from the
> >stable branches. We would also commit to not break a minor
> >release, it should include only bugfixes.
>
> As of now, the master branch is tagged for releases, and a release
> has been made out of master at a given point in time (that is, no
> branch for stabilization or something like that). BTW, IMHO a branch
> for stabilization is less necessary now that we have 'next'.
We don't need a branch for stabilization, master should always be
stable (as in "not broken"). But we should have branches for
stable releases ("stable" as in "no behavioral changes once
branched, only bugfixes").
It shouldn't be a burden to maintain this kind of structure. But
note: what would change is the *number of minor releases* we do.
For example, our current 0.14.1 would be 0.15.0 in this new
process.
Minor versions should be released for the purpose of bugfixing
only and will be interesting to third parties such as Fedora and
stable users of autotest (that's the point of distributing
autotest after all: we want downstream users, and these users
want stability - as in "no behavioral changes").
That's been my point for a while (remember the previous
discussion of splitting the tests from the repository?) We'll
also need versioning in the autotest library and tools, as in
"requires: libautotest > 0.14".
With a larger userbase comes great responsibilities.
(doesn't sound as good as the original, but you get my point) :)
Cheers
- Ademar
>
> >
> >Fedora would probably like to stick to a stable branch during the
> >lifetime of the distro. Ditto for our external users who are
> >concerned with stability.
>
> +1
>
> >
> >This kind of release management is a must if we support
> >out-of-the tree tests.
> >
> >Cheers
> > - Ademar
> >
<snip>
--
Ademar de Souza Reis Jr.
Red Hat
^[:wq!
_______________________________________________
Autotest mailing list
[email protected]
http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
