-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Different stabilities per branch #123
Comments
Andreas, Have you looked at the "per git branch" feature that the Extend Health Utah guys put in? It's file system only at this point, but could that help you sooner? I do like this idea. |
I'll take a look! Another idea would be to support some kind of inline syntax in the ripple config eg:
|
I need to get cranking on this, do you guys see any merit in the "macro" syntax above? can it be simplified? perhaps default to Released always and then:
|
I've got some notes about this. Let me crank out a few things and I'll On Tue, Sep 3, 2013 at 9:07 AM, Andreas Öhlund notifications@github.comwrote:
|
Sounds great! On Tue, Sep 3, 2013 at 4:08 PM, Josh Arnold notifications@github.comwrote:
|
@jmarnold some more background since we follow git flow we've taken the approach that all branches except master,release-* and hotfix-* should build against the latest unstable of their float deps in order to catch incompatibilities as quickly as possible |
@andreasohlund I'm working through 2.4 right now - which involves some major fixes (cleaning the egg off of my face). I'm going to post a roadmap after I push out 2.4 but I'll give you an idea of what I'm working on. I'm working on moving us away from xml for the ripple.config file in favor of our new "Object Blocks" syntax. When that's in place, I'm going to introduce two new things:
We've talked about adding a "lock" file syntax ala bundler. So that you can commit a file to lock your dependencies against a very specific version -- thus making it easier to reproduce a specific build. I haven't thought through it all the way yet but I think the lock/profile features will leverage the same infrastructure (coalescing values). Maybe we make the profile concept conventional as well to support your scenario of branch detection? |
@jmarnold just fyi here is our current hack to make sure we use the correct stability per branch: https://github.com/Particular/ripple/commit/98b25bf69c13b04283463ddc042839e25671d0d0 So in essence the above is what we want to achieve with profiles |
@jeremydmiller @jmarnold I've improved our "hack" so that it might be suitable for inclusion in ripple Can you please review: https://github.com/Particular/ripple/commit/eed79b0a394bfb59defb2c87c3609f4c3903f017 I'll send a pull if you guys think its ok to include In short: If you include a stability convention on your feed the stability will be set based in that convention eg:
Thoughts? |
Based on the discussion here
https://groups.google.com/forum/?hl=en#!topic/ripple-dev/dLAH3dQLSvg
the idea was to introduce a concept of profiles to enable the ripple config to change based on its current environment.
The main use case (for me at least) is to make sure that my master branch is only using stable nugets while my develop branch is using "anything".
Until the profiles are in place could there be any merit in a commandline switch to override the stability settings? --forcestability ReleasedOnly
At least for me that would allow me to tweak my master build to have that setting. Obviously making that convention based is better but still.
The text was updated successfully, but these errors were encountered: