On 23 October 2016 at 23:11, Darren Duncan <dar...@darrenduncan.net> wrote: > On 2016-10-23 3:04 PM, Karen Etheridge wrote: >> >> > 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. > > > Those are my thoughts exactly. If DBIC ever started using multiple > namespaces to distinguish LTS from bigger changes, the LTS should always > have the existing name. Users should always get the "safe" option by > default and explicitly opt-in to risk, rather than the opposite. This > assumes the use of multiple namespaces, and is inapplicable if only one name > is used. -- Darren Duncan
Can we agree on the new governance... first? Then IF (and so far no one seems to have suggested plans for this) there is ever a change that could cause instability or break backwards compat or has any major risk, the voting policy can be enacted to work out what the community wants, new name space for testing with a policy of 6 month release before merging back into main or what ever it maybe, but that is SEPARATE to the governance issue. To me these are two separate issues and it would be good to close off the governance issue before moving onto detail of how to run the project. Thanks Leo _______________________________________________ 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