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. _______________________________________________ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk
