On Wed, Feb 3, 2016 at 8:43 AM, Flavio Poletti <[email protected]> wrote:
> > One direction you might investigate is using Carton > (https://metacpan.org/pod/Carton) for pinning the exact version of the > modules you want to draw from the DarkPAN. This still requires you to > know what goes where, but it should at least allow your DarkPAN to > grow with multiple packages for the same distributon and still be able > to take the right one for the build you want to do. > We use Carton for our CPAN and some DarkPAN dependencies that are never branched to make sure we each developer (and build) has exactly the same dependencies installed. > > > The trouble is we can't have our apps depend on specific versions of > modules because that expects linear versioning, and branching is not linear. > > Carton moves that dependency from the runtime to the installation > time, so it actually allows you to depend on specific versions > ignoring the versioning approach. You might then choose to name your > distribution packages with something related to the commit. > Perhaps I'm missing how Carton helps. Our "github" flow is basically: 1. Developer creates feature/bug fix branch from master in Git. 2. Code is committed on that branch and pull request is created. 3. QA is run on that branch. 4. Once tested the pull is merged back into master. Each release is tagged and built from master. What's left out there is any "dzil release" to our DarkPAN. Going with that flow: Say we have a Catalyst app "Foo::App", and it depends on DBIx::Class schema "Foo::Schema" which is currently at version 1.4. Developer 1 creates their branch, updates code in Foo::Schema, "dzli release" it and now it is version 1.5. They update Foo::App to depend on Foo::Schema 1.5. Then commit to their branch. The problem is when Developer 2 branches at the same time as Developer 1. Their branch does not have Developer 1's changes to Foo::Schema yet. So, when they later dzil release and, say, create version 1.6, that version is missing the changes from Developer 1. It's not backwards compatible. Developer 2 can update Foo::App to depend on version 1.6 and merge back to master, but the version on DarkPAN is missing Developer 1's changes. That's why when we do a release we get a snapshot of master and then build ALL dependencies in that branch into a fresh Perlbrew. That way all the "in-house" (e.g. Foo::Schema) are built from the same branch. It just slow because it's building and running tests for every module each build. Sorry that was so long. Probably making it more complicated than is needed. One options is have perlbrew or a local lib be part of the Git repo, but that's platform-specific and fails with any binary components. Also we have to somehow make sure perlbrew environment vars to point to the right checkout location. Another option is to get rid of some dependencies -- i.e. move Foo::Schema into Foo::App's lib/ directory so that there's no distribution to install. Not ideal, especially if there's also Foo::App2 that also depends on Foo::Schema. -- Bill Moseley [email protected] ------------------------------------------- Dist::Zilla Archives: https://www.listbox.com/member/archive/139292/=now RSS Feed: https://www.listbox.com/member/archive/rss/139292/21080831-4b8afa6a Modify Your Subscription: https://www.listbox.com/member/?member_id=21080831&id_secret=21080831-2b0ee212 Powered by Listbox: http://www.listbox.com
