[Catalyst-dev] Re: When will Catalyst reach 6.0?

[Aristotle Pagaltzis]

* André Walker <andre at andrewalker.net> [2013-12-12 16:35]:
> I agree with changing version numbers, but I don't think we should
> only do that, as the Linux kernel did. I think, in Catalyst's case,
> a new major version number is a great opportunity to break back-compat
> with things that cause problems (make the code base hard to
> understand, and almost nobody uses them anyway). Things like M::, V::
> and C:: namespaces, etc.

That will just delay the version number change. A *lot*. In the meantime
we’ll continue living with crappy version numbers for no good reason.

I also don’t like breaking backcompat like this, on principle almost,
esp. on CPAN, where installing XYZ always means the highest version of
XYZ unless you fight the toolchain hard.

If you break backcompat then it should be done with a new name – not
necessarily a very different one, maybe just e.g. Catalyst2. If that
is decided, there is a *lot* of old stuff that could be thrown away.
The whole Catalyst::Engine getup dates from the pre-PSGI era. All of
the MethodMaker compat stuff that dates to the pre-Moose era. That
dispatcher outer loop. Context/app split. All of those would be much
easier to redo without old user code that must be kept working. Maybe
then the dependency list cut be pared back too. But the result should
not be called Catalyst.

And it would be unreasonable to make sane version numbers wait for it.

Even if you say only a few things should be removed, instead of a big
overhaul like this, it’ll still take longer than you think, and I don’t
know that it would even be worth the pain then.

No. Let’s just fix the version number.

With no attempt to make it mean anything.

It was good enough for Linux – it’s good enough for Catalyst. :-)

(This argument is pretty similar to the ones about timeboxed vs feature-
based releases. The thing is that by trying to make “thematic” releases
you hold up all the *other* improvements from getting to users until the
flagship features are done, which in the case of release schedules has
other bad results as people try various things to evade various effects
of the problem of improvements being held up – often at cross purposes,
making the whole situation worse. You really want to minimize the amount
of “we won’t give users a fix for X until the fix for Y is done”.)

-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>