OK. Here's how it's going to work (for our build server -- you can
obviously checkout and build whatever you want):
For each major release, we will keep a site folder in the releases
folder under the corresponding build version #. For instance,
http://webobjects.mdimension.com/wolips/releases/4118
is the previous stable build, runs on 3.2, etc
http://webobjects.mdimension.com/wolips/releases/4896
is the build that just went stable when I made that announcement
http://webobjects.mdimension.com/wolips/releases/4906
is the build that is RIGHT NOW marked stable -- I put this here,
because I believe this should subsume 4896 if you installed
immediately after launch day.
OK. So that's previous releases. If you like a particular release,
just point your new people to one of these "milestone" folders and
you're good to go. They will never change. Note that we also provide
tar files of just about every build in the releases folder that you
can download to provide a local update site if you want. The
milestone release folders untar'd is just a convenience and identical
to what is available in the releases folder.
This brings us to "stable". Stable on our build server will now
represent the most current commit that we believe is stable. This
WILL change. If you work in an organization where you don't have to
lock down on a specific version, but you always want to stay up-to-
date with what we think you should be using, point to the stable build:
http://webobjects.mdimension.com/wolips/stable
Stable is currently not a branch, it's a trunk version. That means
that right now, if wolips is unstable in nightly, there won't be ANY
stable updates until the trunk is stabilized. Branching is just a big
pain, and unless someone wants to step up and be a branch manager
(including being willing to retest changes that you bring over --
untested partial patch merges are not going to fly), then this is how
it will be. So for instance, just now I committed the new EOQualifier
parser in Entity Modeler. Until I get some reports back on it, stable
is locked at 4906.
And last, but not least, everyone's favorite "nightly". Nightly is
what is has always been ... It's the latest commits.
http://webobjects.mdimension.com/wolips/nightly
We make no guarantees (not that we make any on stable either, but we
REALLY don't on nightly) about whether or not your components and
models will be mangled, your house will catch on fire, or your dog
will run away. All I will say that I run off nightly. It works well
enough to let me do my job. If I stop using nightly, or if someone is
about to commit something sketchy, we'll post about it.
ms
On Mar 2, 2008, at 8:51 PM, Lachlan Deck wrote:
> On 03/03/2008, at 10:11 AM, Anjo Krank wrote:
>
>> I wonder how you except this to work?
>
> Perhaps you'd like to direct your question at Mike. [1]
>
>> 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.
>
> I wondered how this would work also... but it /was/ Mike's proposal.
>
>> 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.
>
> Which you've already noted previously.
>
>> 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,
>
> That depends. We've already seen numerous examples of Mike holding
> things back even from nightly (e.g., classpath changes) when they
> would have a broader impact. This could free him up some more to not
> be so cautious and as such get a broader testing base for those who
> are willing.
>
> Again, Mike could perhaps explain his thinking on these things.
>
>> 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.
>
> If providing 'ideas' to think on (whether perceived by some as pros
> or cons) should Mike choose to go with what's previously been
> suggested by /him/ somehow shows some lack of understanding on my
> part in your eyes, so be it.
>
> I'm not asking for this to be done... but should it happen, the
> ideas I provided could be one of the spin-off benefits.
>
> Perhaps at this point it would be better to ask Mike if he's got a
> clearer idea about what he proposed. But then again, maybe he's
> already gone ahead and done it as he's not one to sit around.
>
>> 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
>
> [1] This was /his/ proposal, which you even noted -- though you
> still seem to think it's somehow an idea /I/ need to explain and
> that somehow it shows some lack of understanding on my part about
> the facts of life.
This archive was generated by hypermail 2.0.0 : Mon Mar 03 2008 - 15:16:17 EST