I also like the idea of default dbic being the stable one, and the dbic2 being opt in. +1
-- sent from a rotary phone, pardon my brevity On Oct 23, 2016 1:21 PM, "Andrew Beverley" <a...@andybev.com> wrote: > On Wed, 5 Oct 2016 04:07:04 -0400 David Golden <x...@xdg.me> wrote: > [...] > > * DBIx::Class (DBIC) – Peter's work provides a capstone, with only bug > > fixes thereafter > > * DBIx::Class2 (DBIC2) – new feature development, with lower stability > > expectations > > > > Some of the benefits I could see from this: > > > > (1) It helps DBIC users avoid getting upgraded past a stability point > > without having to learn to pin module versions or change application > > code to use a different package name. People have to positively > > opt-in for some risk in exchange for new features by asking for DBIC2 > > explicitly. > > > > (2) The relation between the two is more immediately obvious than > > between, say, DBIx::Class::Stable and DBIx::Class. It also seems > > more like one project than two, particularly if both are under the > > same governance, use the same mailing list, etc. > > > > (3) It sets a possible path forward of DBIC2 evolving new features > > for a while and then eventually moving into a bug-fix-only state > > while the next generation of new features go into a future DBIC3. > > > > There is some precedent for "Foo" evolution going to "Foo2" such as > > Dancer/Dancer2, Test/Test2, and probably others. Those have bigger > > disruptions from old to new than I imagine DBIC2 having (initial > > release of DBI2 probably being a carbon copy of the final version of > > DBIC), but at least its a naming pattern that people will recognize. > > I'm coming round to this idea. I was originally against it as I assumed > that it would be little more than a version freeze with no ongoing > maintenance, but given the more recent discussions, I wonder whether > this might be the best solution, if: > > - Riba was prepared to keep maintaining (and "tightening" in slower > time) "DBIC", with its current set of features, thereby making it a > rock-solid module, still maintained, that can be used in critical > applications which only need the current feature set. > > - the previously-proposed committee creates and maintains "DBIC2", > which becomes almost a testing ground, production ready, but for those > that want to live slightly closer to the edge. > > Longer term, code could be ported from DBIC2 into DBIC. > > Andy > > _______________________________________________ > 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
_______________________________________________ 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
