> I also like the idea of default dbic being the stable one, and the dbic2 being opt in. +1
I don't see how it could credibly be the other way. There is no way to get informed consent from all the existing DBIx::Class users to ensure that they understand they are getting bleeding-edge code. Moving to a more risky configuration must always be done intentionally. On Sun, Oct 23, 2016 at 3:00 PM, fREW Schmidt <fri...@gmail.com> wrote: > 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 >
_______________________________________________ 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
