On 7/31/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> Robert Burrell Donkin ha scritto:
> > trunk has been dubbed 'next-major' for a long time now. a lot of extra
> > function has been added to trunk and though a full release is
> > definitely a long way in the future, the time seems right now to
> > decide that a future release from this code stream will be designated
> > 3.0.
>
> This is not correct,

(IMHO correct but incomplete: the artifacts created by the trunk build
are named next-major)

> let me explain:
> next-major was the name assigned to a tentative release and branching
> trunk was in the plan for next-major. The difference between trunk and
> next-major was in the planning/scheduling and was present in JIRA when
> we used this labels to discuss what was going to land next-major
> (storage/config compatible) and what would have had to wait the
> following (storage/config incompatible).

i would prefer the storage/config compatibility issue to be managed by
experimental modules. this means that people can code whatever new
features without having to wait for some future next-major to be cut.

> > dubbing trunk 3.0 does imply that if the 2.x code base requires a new
> > major release then this will take the 4.0 designation. i have no
> > problem with that contingency.
>
> I don't understand this sentence. Can you explain?
> AFAIK no one ever though to create major releases starting from the 2.x
> branches. The only proposal we had was for a minor release based on 2.x
> (and if Noel will come back sooner or later with this goal I think we
> all already agreed on the 2.4 number)

just thinking about contingencies: would probably have been cleaner
and clearer to avoid speculating about the future right now.

<snip>

> In fact I think it should be better to define what to release and then
> define the number to use, but I'm fine with *any* number as long as it
> doesn't affect releasing asap (trivia: the trunk in 2004 was named 3.0).
> I would like to know if the goal to keep storage/config.xml
> compatibility is a priority in the 3.0 or not: IMHO this is the only
> important thing to be able to dedice what can be included in trunk and
> what will have to wait for trunk to become a branch.

i think that it helps to have a good name for a distant collective goal

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to