[torquedev] Versioning Issues & Development Roadmap
garrick at usc.edu
Thu May 28 23:20:35 MDT 2009
Agreed. My point is that development shouldn't happen in fixes branches.
HPCC/Linux Systems Admin
On May 28, 2009, at 8:47 PM, Glen Beane <glen.beane at gmail.com> wrote:
> 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
>>>> 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
More information about the torquedev