2008/11/18 Ludovic Courtès <[EMAIL PROTECTED]>:
> Hi,
>
> Andy Wingo <[EMAIL PROTECTED]> writes:
>
>> Beating a dead horse, 1.8.5 should be compatible with 1.8.3, via
>> whatever mechanism. (The actual problem in this case was elsewhere.)
>
> 1.8.5 *is* compatible with 1.8.x.
>
>> I am skeptical of pushing significant changes into stable branches. I
>> really don't want to be in the situation in which 1.8.4 works for
>> someone, but 1.8.7 does not. You might be right, Neil, about that path,
>> but it does not give me warm fuzzy feelings.
>
> Same for me, but we can surely find a reasonable trade-off.
Many thanks everyone for your replies to this thread, and sorry for my
delay in following up.
OK, it's clear the consensus on 1.8.x is against my suggestion, so
I'll accept that. And I can understand the reasons too. I think
perhaps it comes down to Ludovic's point about the version number
being a hint - i.e. people already have expectations about what should
be in the change from 1.8.x to 1.8.x+1, and mostly those expectations
seem to be API and ABI compatibility, so it makes sense to comply with
that.
One of my background concerns, when suggesting that we try to get more
into 1.8.x, was that if we have lots of release branches (e.g. 1.6.x,
1.8.x and 1.10.x) in use at the same time, we have to do more work to
apply fixes to all branches. But in fact that is a lot easier now
that we use Git, so probably isn't a big worry.
For new features, then, the question becomes: what is our general
plan, from here on, for going from 1.y.x to 1.y+2.0 ? As Greg has
said, we need to get new stuff out quicker than we have done in the
past. Right now we have an growing pile of new stuff in Git, should
_all_ of that go into 1.10?
I guess the answer is that 1.10.0 - and more generally any new 1.y+2.0
- should include everything that we have which
- we believe is ready, i.e. in a sufficiently final form that its
API/ABI is unlikely to be broken in future
- is working.
For 1.10.0, then, we just need to check that there isn't anything in
master that isn't ready/working; if there is, it should be moved into
a branch. And from here on we should adopt the rule that new features
are always developed on branches, and only merged into master when
ready and working. Then we should be able to release master as a new
1.y+2.0 whenever we see that enough new features have accumulated.
How does that sound?
Neil
