Hm.
I wonder how you except this to work?
Not only we(*) have to write the code, but the more nightly advances,
the higher is the chance that you can't simply apply a patch from the
trunk to the stable version and still expect it to actually do what it
does there. Not only the compile could break, but also someone needs
to fully test it.
If it was me doing this, I'd only advance nightly and declare it
stable whenever I feel like it. Maybe disable features I don't know if
they work by properties or settings. Having to maintain more than one
version is just too much hassle.
Sure, having the pick between 3 versions is nice, but seriously, if
you're daring enough to pick "preview" you might as well pick a
nightly, and if you find a show-stopping bug, report it. Last I looked
the response times to that where like 15 mins.
You (**) don't seem to realize that this time will come out from
*somewhere* and it most likely be our actual jobs, new Ajax features
or new WOLips features.
Which, btw is why Wonder doesn't have a "stable" version either. The
committers only use the trunk for production and it almost always is
"stable" enough. So the additional work of maintaining a branch isn't
really worth it.
And people who are updating daily automatically should get their heads
examined in the first place... don't you have any real work or not
enough problems on your own ?+)
Cheers, Anjo
*) "we" is the official term for "WOLips committers", but let's not
kid ourselves who is meant by that
**) I know that it was a "WOLips committer" who came up with the idea,
maybe this committer thinks he'd rather skip a few hours of sleep
instead
Am 02.03.2008 um 04:24 schrieb Lachlan Deck:
> On 01/03/2008, at 2:04 PM, Mike Schrag wrote:
>
>> This is sort of what I'm leaning towards, too. But I don't know if
>> people expect "stable" to be "stagnant" :)
>
> Hmm, for me stable equals more reliable rather than stagnant.
>
> But if you are going for three streams (Nightly, Preview, Stable)
> rather than two (Nightly, Stable) then by nature Stable will/should
> only receive critical bug fixes. Preview, then, will be like beta
> releases previewing the next stable release... etc.
>
> Perhaps you'd want to think about locking of new features from
> Preview at certain times when aiming at pushing to Stable a new
> release so as to iron out any remaining bugs?
>
>> On Feb 29, 2008, at 9:51 PM, Johan Henselmans wrote:
>>
>>> Op 1 mrt 2008, om 01:09 heeft Mike Schrag het volgende geschreven:
>>>
>>>> So there are a couple bug fixes I've just committed ... What do
>>>> people prefer? Do you want bug fixes to move to stable, or make
>>>> no changes to stable until we do the next major release?
>>>
>>> If it makes stable more stable...
>>>
>>> Move bugfixes to stable. Hardly tested experimental stuff into
>>> nightly.
>
> with regards,
> --
>
> Lachlan Deck
>
>
>
This archive was generated by hypermail 2.0.0 : Sun Mar 02 2008 - 18:13:37 EST