[Dbix-class] IMPORTANT: A discussion of DBIC governance and future development

[Matt S Trout]

On Sun, Oct 23, 2016 at 04:30:12PM -0400, Ashley Pond V wrote:
> I am of a similar mind. I want to have both code paths and this seems
> like the only way to do that.

I worry a lot about the costs to the ecosystem of split effort.

There's a lot of DBIx::Class::* out there,

On the other hand using the bundling trick to allow application developers
to say

  use DBIx::Class::LTS;

and get the normal DBIC namespaces could work very well, *if* you could
resource the backcompat oriented volunteer time required to maintain it.

That way a straight 'cpanm DBIx::Class' would continue to provide up to date
code, anybody who wants to wait-and-see can do so, and the ecosystem doesn't
get forced to fork.

It also strikes me that a 'use DBIx::Class::Current;' or something to have
a non-dev release of something we think still needs burning-in time might
also be interesting.

Right now though, personally, I'm more focused on rebuilding a team that
can manage to successfully manage a single DBIC codebase. I suspect that's
going to be quite enough challenge for the moment.

-- 
Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue

http://shadowcat.co.uk/blog/matt-s-trout/   http://twitter.com/shadowcat_mst/

Email me now on mst (at) shadowcat.co.uk and let's chat about how our CPAN
commercial support, training and consultancy packages could help your team.