[Lazarus] Release schedule and policy

[Juha Manninen]

On Friday 22 October 2010 21:08:27 Martin wrote:
> > To support this process, any new big feature should stay in its own
> > branch first and be merged to trunk some time after a release (not just
> > before a release).
> 
> I am not sure this is a goof idea.
> 
> 1) Who defines what is a major feature?
> 2) we do not want 20 or 30 different branches?

No, my idea was that only a new feature which is guaranteed to be broken at 
the time of next release date, is kept in a branch until the release. Then it 
can be merged and tested by all trunk users. It will make it into the next 
release. For example if you start a new "Enhanced Smart Tabs" feature a month 
before a release, and it will surely mess everybody's code at that moment, 
then it should go to a branch.

There would not be very many such branches. It would just be a compromise 
between the current situation when everybody must use the development version 
and suffer from its broken stuff, and the goal to make a "perfect" release when 
"all bugs are fixed".

[...]

> Then you would have one or 2 maintained branches:
> a) the fixes branch as currently
> b) the next release branch, which is based on fixes, but also gets
> features merged as soon as they are deemed stable. Some end-users may
> even want to stick with this.
> 
> And those 2 branches, are what will take a lot of work. If someone is
> willing to do that work, then I guess that's all it takes.

I had a different idea here (if I understood your text right).

The next release would be based on trunk only. It means it would not be stable 
and well tested. Later it would have maintenance-patches and -releases and 
would become more stable.
Having a certainly broken feature in a branch and excluding it from release 
tries to make the initial release more stable than the trunk currently is.
The release maintenance branches would get only bug fixes, no new features.

This is all about finding a good compromise. The current situation is not good.


> Well I think, the commiter can flag them with some sort of hint, the
> maintainer decides.

That would be good.

> Depending on how much work the maintainer wants to spent, I would
> suggest, that each fix, should stay one or two weeks in trunk, before
> being merged anywhere else. That way, if it breaks something else we may
> spot it before merging it.

Makes sense.

Juha