[Lazarus] Release schedule and policy

[Martin]

I took the liberty to reorder your statements

On 22/10/2010 18:35, Juha Manninen wrote:
> I would like to suggest again a new release policy. It would have timely
> releases, meaning a new release after a fixed time period, at a predefined date.
> Some projects have a 3 months cycle but a 6 months would be enough for Lazarus
> because of more limited resources.
>
> I could help somehow in this process. I believe that lack of resources is a
> problem when implementing such a model.

I guess: yes, you hit the nail on the head.

> 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?
3) New features would take longer, since they were no longer tested.
Of course, the end-user a forced tester would anyway no longer be there 
(since they could stick to releases), but at least other developers 
would still use all new features.
Personally, I don't mind the occasionally issue with the IDE caused by 
somone elses new work. I do the same sometimes, and I am always glad to 
get feedback as soon as possible, as it makes it much easier to fix the 
issue.

I believe, trunk should stay open for all work (extremely experimental 
work can and should go into branches, as has in the past).

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.


> Every release would be basically cut out from trunk. It would be verified to
> compile and to work with some big test projects. Nothing else. Then it could
> be called "release x rc1". After one week testing and maybe applying fixes from
> trunk, it would become the "release x" (without rc1). After that there would
> be maintenance releases in a timely fashion (or when needed).
See above.

There are also some existing test cases. They could even be used on the 
"b" branch from above, on every merge..., but again: maintenance resources.


> The important point is that emphasis would move from the release itself to its
> maintenance. The challenge is to find all needed fixes for the maintenance and
> to apply them.
> Basically all commits in trunk could be classified as "feature" or "bug-fix".
> Bug-fixes should be applied also to maintenance branches. The division is not
> always clear.
> Who classifies them, the author of the commit or the branch maintainer?
Well I think, the commiter can flag them with some sort of hint, the 
maintainer decides.

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.
Or it first merges into "b"-next-release, and if no complaints are 
received, then into fixes

....

my 2.5  cents
Martin