On Fri, Dec 17, 2010 at 12:10 PM, Alexis Sukrieh <sukria@sukria.net> wrote:

I agree, using the 1.3 releases serie for deprecating stuf inn 1.2 sounds good. Making them fatal error in 1.4 makes sense.

This strategy sounds good: release series with even number (1.2, 1.4, 1.6, ...) always contain stable features, intermediate series can deprecate things in the previous serie (1.3 can deprecate, with warnings, stuff in 1.2).

The trick here is to get people to actually go through the 1.3 release branch or they will be not be able to transition easily. If they go through deprecating releases they'll get warnings on what to fix. If they don't, things will just break.

This is the downside of it and usually why I don't support such behavior.

So:

1.2xxx => stable codebase, no deprecation, no new features
1.3xxx => development codebase, deprecation, new features

Like I said, the problem here is that people will generally prefer to avoid development branches, meaning that jumping from one stable release to the other (without the deprecation stage) will leave them broken.

I suggest we start deprecating now.
1.2xxx => stable + deprecations
1.3xxx => new release, stable + breaking old deprecations

That way we'll get people to definitely go over deprecations (when they stay within the certain branch, such as 1.2x). This means we'll also not confuse people with "development branch", "stable branch", etc.

The important note here is that *deprecation is not breakage*. We are not breaking them, only reporting behavior which will be broken in a future release branch (such as 1.3x, or whichever the next one is).

This also reminds me we need a new permanent branch on the repo, like experiemntal, where we will build releases for 1.3

I use such a layout at work, and it works pretty well (with git-flow configured in two different ways):

2.0000
-[ master ]------------------------------|----------------------->

-[ devel ]--+----------------------------+---------------------->
\ /
\-[ topic/XXXXX ]--------/

This is what I use too and I find it very successful. We're going to start using it at $work as well.

This layout is good for maintaining one release cycle, but if we want to provide development releases in parallel (1.3xxx) we need one more branch. Otherwise it will be veru difficult to maintain the 1.2 serie.

I am personally against it. I don't want to start seeing multiple versions of things and start working on backporting features from here and there. This is a great pain to Linux distributions and it shouldn't be for us.

My view is this:
Every release series should have its own deprecations.
Every release series can break a deprecation that appeared in a previous release series: 1.2x can break stuff that were deprecated in 1.1x. 1.3x can break stuff that were deprecated in 1.2x.
There is no "development series" that people will prefer to overlook.
Perl itself will not deprecate in a development and break in a stable. They will deprecate in the development, carry it to the stable (since the development is just a development track for the stable release) and then they will break it in a much futuristic version of the development which will become the next stable.

My main concer is how can we publish those releases on CPAN...

That's one of my main concerns. Another is how we manage it ourselves. It seems to me like a development and maintenance nightmare. Another concern is that people avoid using "development versions" and if that's the place where we deprecate, they won't even know it.

All the best,
Sawyer. :)