[Development] Setting up time-based releases for the project
charleyb123 at gmail.com
Tue Aug 7 20:24:41 CEST 2012
> <snip,> As one of those who is working towards being a new contributor, I
> would want a use a generally stable branch for most of the initial work of
> adding a new module; and then move it up towards "fire-hose" just prior to
> pushing it out to everyone.
> That is:
> - Grab the 6 month release and do the work; syncing as necessary.
> - Once most things are working, then work towards integrating to one of
> the faster releases, and eventually to the regular dev tree.
> - Once in the regular dev tree, then work with everyone to actually push
> it out into an official release and back down the tree.
> To me this makes sense as it allows me more stability while doing the work
> for an add-on module.
> I would suggest we consider this view as well to at least have it
> documented on what we recommend - whether it is the above or something else
> entirely. At least it would be somewhere where people looking to add new
> features will be able to look.
> $0.02, fwiw
Agree: That's probably how I'd work too.
Honest question, this isn't a proposal, but don't we have *TWO* issues
(1)- "Levels-of-stability" (for the next release)
(2)- "Evolving-APIs/Features" (for future releases)
I don't want to "explode" the issue, but that seems to imply (to me)
*- NextMajorRelease (API changes allowed)
*- NextMinorRelease (source compatible)
*- NextDotRelease (binary compatible)
We're using "Git", after-all, and merges are simple (it is built to merge
...Is this stupid/confusing/too-much-work?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Development