<div dir="ltr"><div class="gmail_default" style="font-size:small">> I also like the idea of default dbic being the stable one, and the dbic2 being opt in. +1<br><br></div><div class="gmail_default" style="font-size:small">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.<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Oct 23, 2016 at 3:00 PM, fREW Schmidt <span dir="ltr"><<a href="mailto:frioux@gmail.com" target="_blank">frioux@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">I also like the idea of default dbic being the stable one, and the dbic2 being opt in. +1</p><span class="HOEnZb"><font color="#888888">
<p dir="ltr">-- <br>
sent from a rotary phone, pardon my brevity</p></font></span><div class="HOEnZb"><div class="h5">
<div class="gmail_extra"><br><div class="gmail_quote">On Oct 23, 2016 1:21 PM, "Andrew Beverley" <<a href="mailto:andy@andybev.com" target="_blank">andy@andybev.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, 5 Oct 2016 04:07:04 -0400 David Golden <<a href="mailto:xdg@xdg.me" target="_blank">xdg@xdg.me</a>> wrote:<br>
[...]<br>
> * DBIx::Class (DBIC) – Peter's work provides a capstone, with only bug<br>
> fixes thereafter<br>
> * DBIx::Class2 (DBIC2) – new feature development, with lower stability<br>
> expectations<br>
><br>
> Some of the benefits I could see from this:<br>
><br>
> (1) It helps DBIC users avoid getting upgraded past a stability point<br>
> without having to learn to pin module versions or change application<br>
> code to use a different package name. People have to positively<br>
> opt-in for some risk in exchange for new features by asking for DBIC2<br>
> explicitly.<br>
><br>
> (2) The relation between the two is more immediately obvious than<br>
> between, say, DBIx::Class::Stable and DBIx::Class. It also seems<br>
> more like one project than two, particularly if both are under the<br>
> same governance, use the same mailing list, etc.<br>
><br>
> (3) It sets a possible path forward of DBIC2 evolving new features<br>
> for a while and then eventually moving into a bug-fix-only state<br>
> while the next generation of new features go into a future DBIC3.<br>
><br>
> There is some precedent for "Foo" evolution going to "Foo2" such as<br>
> Dancer/Dancer2, Test/Test2, and probably others. Those have bigger<br>
> disruptions from old to new than I imagine DBIC2 having (initial<br>
> release of DBI2 probably being a carbon copy of the final version of<br>
> DBIC), but at least its a naming pattern that people will recognize.<br>
<br>
I'm coming round to this idea. I was originally against it as I assumed<br>
that it would be little more than a version freeze with no ongoing<br>
maintenance, but given the more recent discussions, I wonder whether<br>
this might be the best solution, if:<br>
<br>
- Riba was prepared to keep maintaining (and "tightening" in slower<br>
time) "DBIC", with its current set of features, thereby making it a<br>
rock-solid module, still maintained, that can be used in critical<br>
applications which only need the current feature set.<br>
<br>
- the previously-proposed committee creates and maintains "DBIC2",<br>
which becomes almost a testing ground, production ready, but for those<br>
that want to live slightly closer to the edge.<br>
<br>
Longer term, code could be ported from DBIC2 into DBIC.<br>
<br>
Andy<br>
<br>
______________________________<wbr>_________________<br>
List: <a href="http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class" rel="noreferrer" target="_blank">http://lists.scsys.co.uk/cgi-b<wbr>in/mailman/listinfo/dbix-class</a><br>
IRC: <a href="http://irc.perl.org#dbix-class" rel="noreferrer" target="_blank">irc.perl.org#dbix-class</a><br>
SVN: <a href="http://dev.catalyst.perl.org/repos/bast/DBIx-Class/" rel="noreferrer" target="_blank">http://dev.catalyst.perl.org/r<wbr>epos/bast/DBIx-Class/</a><br>
Searchable Archive: <a href="http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk" rel="noreferrer" target="_blank">http://www.grokbase.com/group/<wbr>dbix-class@lists.scsys.co.uk</a></blockquote></div></div>
</div></div><br>______________________________<wbr>_________________<br>
List: <a href="http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class" rel="noreferrer" target="_blank">http://lists.scsys.co.uk/cgi-<wbr>bin/mailman/listinfo/dbix-<wbr>class</a><br>
IRC: <a href="http://irc.perl.org#dbix-class" rel="noreferrer" target="_blank">irc.perl.org#dbix-class</a><br>
SVN: <a href="http://dev.catalyst.perl.org/repos/bast/DBIx-Class/" rel="noreferrer" target="_blank">http://dev.catalyst.perl.org/<wbr>repos/bast/DBIx-Class/</a><br>
Searchable Archive: <a href="http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk" rel="noreferrer" target="_blank">http://www.grokbase.com/group/<wbr>dbix-class@lists.scsys.co.uk</a><br></blockquote></div><br></div>