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

[fREW Schmidt]

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" <andy at andybev.com> wrote:

> On Wed, 5 Oct 2016 04:07:04 -0400 David Golden <xdg at 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 at lists.scsys.co.uk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scsys.co.uk/pipermail/dbix-class/attachments/20161023/51e26bb7/attachment.htm>