[torquedev] Versioning Issues & Development Roadmap

Glen Beane glen.beane at gmail.com
Thu May 28 21:47:34 MDT 2009

yeah,  I guess that was my point.  Not ALL development should happen in trunk.

I think development of major versions should happen in a branch,
because by definition these are involving big changes that either are
incompatible or are long-term development projects, and trunk should
be the next minor version.

On Thu, May 28, 2009 at 11:42 PM, Garrick <garrick at usc.edu> wrote:
> (sorry, bottom posting is a pain on iPhone)
> Fork a private branch for the long-term change and keep it sync with trunk
> while you work on it. Eg ipv6 branch.
> Keeping the private branch in sync with trunk and later merging your changes
> back into trunk is easy.
> HPCC/Linux Systems Admin
> On May 28, 2009, at 8:37 PM, Glen Beane <glen.beane at gmail.com> wrote:
>> On Thu, May 28, 2009 at 11:29 PM, Garrick <garrick at usc.edu> wrote:
>>> There's nothing wrong with the versioning scheme, just stop adding
>>> features to "fixes" branches and do all development in trunk. Fixes
>>> are always backported from trunk down to all supported branches. As
>>> long as changes in trunk are backwards compat, then new releases keep
>>> the same major number.  Easy.
>>> Current trunk should stay on track as 2.4.
>> There are cases where you want to be able to be working on the next
>> minor release and the next major release at the same time.  A major
>> release could be a long-term project, during which several minor
>> releases may happen (with bug fixes and minor features back ported
>> from the major version in development).  If it is going to take you a
>> year to make some major change you don't want to put a halt to minor
>> version releases.
>> _______________________________________________
>> torquedev mailing list
>> torquedev at supercluster.org
>> http://www.supercluster.org/mailman/listinfo/torquedev

More information about the torquedev mailing list