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

[Aristotle Pagaltzis]

* John Napiorkowski <jjn1056 at yahoo.com> [2013-12-14 21:35]:
> Of all the things potentially need of fixing in Catalyst, its not
> clear to me that version numbering is one of them...

In what sense is it even comparable to other things that need fixing?

Even if it was, I call shenanigans on that line of argument. “Given
cancer and world hunger, does it even make sense to worry about bugs
in Catalyst?” There is *always* something bigger to fix, so this line
of argument can be used to derail/torpedo *any* fix. So I consider it
meaningless.

> I know the system has changed around a bit and there's a claim that
> this is somehow causing trouble with downstream maintainers (I guess
> by this you people like Debian or Red Hat making *.deb / *.rpm).  Can
> someone point out to me a clear example of this, or a clear case where
> the current version system causes trouble?  By this I mean a use case,
> like some technical task that cannot be completed or where the
> workarounds are onerous and fragile.

The issue boils down to nobody agreeing on exactly how the fractional
parts of two version numbers are to compare. The only agreement that is
usefully close to universal is about the non-fractional part being
numerically comparable. Hence my proposal, bump the major version so the
fractional part can be fixed.

> Personally I would otherwise prefer not to get into a bike shedding
> discussion about what is the best version number for Catalyst, in the
> absence of such a use case. I suspect the confusion caused would
> outweigh any gain that I can possible see.

… confusion?

About what?

> Currently the process that I am using to introduce change into
> Catalyst involves one of three evaluations:
>
> 1) Its a bug that needs fixing or improvements to clarify the documentation.
> 2) Community consensus.
> 3) Technical Merit.

How is any of that even applicable when we’re talking about bumping the
version number which happens every single time Catalyst is released?

> In all three cases I want to weigh the proposed change against the
> possible harm, such as the impact on back-compat or an increase in the
> dependency count, performance changes, memory requirements, etc.

I can’t think of any reason this would break backcompat, but if anyone
else can, please explain. Other possible harm: dependency count: no
change. Performance changes: none. Memory requirements: identical. Etc.

> Generally I want to see the value outweigh the harm and that steps
> are taken to provide workarounds or some type of mitigation (such as
> a clear deprecation cycle as we are doing with the Regexp dispatch
> support).
>
> So all things being equal, I'll prefer to respect tradition and
> back-compat, even if doing so involves some hassles or pain for us.

If my impression that there is no harm here holds up, then the value of
this change can only possibly outweigh the (zero) harm.

> I realize this leads to slower change than many people, including
> myself, want to see. If you want to see Catalyst move faster I invite
> you to participate in nominating tasks and detailing them. The current
> quest list for the proposed upcoming development cycle is here:
>
> http://questhub.io/realm/perl/explore/latest/tag/runner
>
> I am considering one or two more ideas, but I also have to plan for
> the current level of contribution. I do not like to make plans and
> fail :) The current contribution level suggests its smarter to focus
> on small, useful tasks that can be completed by one person in 4 to 20
> hours of time. This is the process I have followed for the previous
> year, and I think its resulted in strong, incremental improvements to
> Catalyst, including movement on some tasks that have been stuck for
> a number of years.  If you have followed this year's Catalyst Advent
> I would hope you'd feel the same way.

I have no objections of any kind to any of this. It is a smart way to
cope with reality.

> I do have some thoughts about ways we can manage back-compat while
> allowing us some greater ability to make deeper changes; They will be
> summarized in this year's final advent article, so I recommend
> following if you are not currently doing so:
>
> http://www.catalystframework.org/calendar/
>
> I don't want to make plans or promises that can't be kept, because it
> hurts our community. For example, there was a huge effort put into
> projects like the port to using Bread Board, and several attempts at
> splitting $app/$ctx but that time ended up not bearing fruit and
> I personally felt bad because I know how much it sucks when you put
> your free time into something and it doesn't work out.  So I make
> a clear promise that if we set a goal we will achieve at least 85% of
> it, and by that I mean at least 85% successful changes introduced into
> a stable version of Catalyst on CPAN (not 85% a project completed but
> still stuck in a branch, which I consider effectively 0%).
>
> Thanks!

Does this mean that if I prepare a patch to bump the version number so
that you can simply apply it, you will take it?

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