5.0 and or 4.8 (was Re: [development] Drupal x.x.0 freeze date)

[Larry Garfield]

I am going to partially agree.

4.7 has been in theoretical feature freeze for something like 6 months.  It 
wasn't always enforced that well, but in theory it was. :-)  That means 
there's a backlog of smaller features or niceties that were put aside in 
order to not break things even more than FAPI did.  I know I have 3-4 sitting 
in the patch queue marked postponed that I've been holding off on for that 
reason.

Saying that 4.7+ will be a smaller "polish and flesh out" release is a good 
idea.  It gives us a chance to take the now (mostly) stable FAPI and flesh it 
out, get in lots of the convenience features that have been held back 
recently, debug some more, and so forth, and make 4.8 a really solid, 
complete, stable, if not-earthshattering-after-4.7 release.  Smaller API 
changes are OK (they always happen), but ground-shaking changes should be put 
off.

It's important to have that really solid and polished release out there, 
because you know that the big stuff that comes after it is going to take as 
long as FAPI did to stabilize.  That means it will be "out there" for a LONG 
time.  

I think of it sort of like the KDE 4 roadmap, honestly.  KDE 3.5 was 
deliberately a conservative "polish and perfect the 3.x series" release, 
because they knew that 4.0 was going to break stuff, take a year or more to 
come out, and then another year before many distros get over their 
x.0-release phobia.  That's a good, pragmatic plan, and I see good reason to 
emulate it.

I don't know that we need a separate 5.0 branch right now, though.  Really big 
changes should be made in their own private branches (that's what branching 
is for), or perhaps even their own separate repositories as FAPI was.  
They're going to take a while.  If the 4.8 cycle is short, then they wouldn't 
need to go into a mainline tree until after the 4.8 freeze anyway.  And, of 
course, we could use the manpower on polishing 4.8.

There would need to be some sort of coordination betwen the different 
big-changes groups to make sure they all are breaking things in the same way, 
but that's what a release manager is for: to make sure that the 
everything-is-cck group and the OO-theming group and the 
all-sql-is-autogenerated group are not pulling in 4 different directions.  

As for codenames, the 4.7/5.0 question is why they exist. :-)  I'm game.  

On Sunday 30 April 2006 02:40, Bèr Kessels wrote:
> Now that this has been brought up, I'd like to put forward my thoughts or
> idea.
>
> * split out 4.8 and 5.0
> * hard freeze date for 4.8
> * roadmap for 5.0
>
> Split 4.8 and 5.0:
>  We all have Great Plans for 4.8. Those Great Plans are all of the
> magnitude of Fapi. Stick two such overhauls in one release, and we **know**
> its not going to be possible to release anytime soon. That is a pity for
> all the small changes (ajax, freetagging, etc) that people want, but are
> unavailable, because we cannot release 4.8 because all the Big Plans are
> holding it up.
>
> 4.8 for all the usual stuff. (pragmatism)
> 5.0 for the big re-hauls, gigantic plans and huge patches. (freedom)
>
> Two possible problems, though: People are too busy with one (4.8) to put
> full attention on another (5.0). And patches will often need to go into two
> branches: more work, more maintenance.
> I think both are small problems compared to the amount of freedom (5.0) and
> pragmatism (4.8) we gain trough this; There are enough people out there
> anyway, but 5.0 will need no/less testing until its somewhere stable. So it
> needs far less people. Patches that need to be maintained in pairs: I don't
> think that will be the case often. After all: what good will "a small
> theming improvement on aggregator output" patch do in 5.0, if in 5.0 the
> "big theme overhaul to make all output structural, like fAPI" patch is
> already in? Patches will be so different that those that apply to both
> branches have to maintained separate anyway.
>
> Hard freeze date for 4.8.
>
> > What does everyone think of hard feature freeze on September 1st? That
> > gives us approximately 4 months of development time.
>
>  Neil proposes Sept. 1st. to be a hard freeze date.
> If we don't have to worry about huge patches, that FUBARed core, this is
> doable. If we are going to implement all the wild plans, in a single branch
> (when we do not split 4.8 and 5.0) this is not going to be possible.
> Esp small bugfixes and features will become unmaintainable, because core
> changed completely every month or so :). And off course, having two or
> three Huge projects breaking everyhing requires an unknown amount of time
> to stabilise (fAPI is *still* not really stable). No roadmap is needed, for
> 4.8. It can simply be a 'What is in by Sept 1st, is in. The rest is not.
> Fullstop".
>
> Roadmap for 5.0
>  Because the 5.0 does not aim at a release date, but at a set of goals
> (world domination ;) ), I think it will be a good idea to make a roadmap
> for this. Obviously we'd need a gatekeeper to maintain that roadmap, to
> provide it from growing unworkable big. If the release for 5.0 will be
> aimed around a year, a year and a half from now, that roadmap can still be
> big enought to put all our big ideas in.
>
> This, BTW is how a lot of projects work towards big releases.
>
> Bèr

-- 
Larry Garfield			AIM: LOLG42
larry at garfieldtech.com		ICQ: 6817012

"If nature has made any one thing less susceptible than all others of 
exclusive property, it is the action of the thinking power called an idea, 
which an individual may exclusively possess as long as he keeps it to 
himself; but the moment it is divulged, it forces itself into the possession 
of every one, and the receiver cannot dispossess himself of it."  -- Thomas 
Jefferson