[Development] Setting up time-based releases for the project

[Charley Bay]

 Ben spaketh:

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

Agree:  That's probably how I'd work too.

Honest question, this isn't a proposal, but don't we have *TWO* issues
being considered?

 (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)
something like:

 *- NextMajorRelease (API changes allowed)
    *- master
    *- beta
    *- stable
 *- NextMinorRelease (source compatible)
    *- master
    *- beta
    *- stable
 *- NextDotRelease (binary compatible)
    *- master
    *- beta
    *- stable

We're using "Git", after-all, and merges are simple (it is built to merge
across branches).

...Is this stupid/confusing/too-much-work?

--charley
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120807/dd743b36/attachment.html>