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

Karen Etheridge perl at froods.org
Sun Oct 23 22:04:32 GMT 2016


> 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 <frioux at 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" <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
>
>
> _______________________________________________
> 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/4f94a595/attachment-0001.htm>


More information about the DBIx-Class mailing list