-
-
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
Bump build number to add session management after re-building Qt with it #7
Conversation
…t with it [skip appveyor]
Hi! This is the friendly automated conda-forge-linting service. I just wanted to let you know that I linted all conda-recipes in your PR ( |
@ocefpaf, how can I skip Appveyor and Travis to create packages after I merge this one? |
Carlos, only phone here so I am probably missing the context. Why do we Either way just merge as-is and do not worry about the failures as no On Oct 15, 2016 7:39 PM, "Carlos Cordoba" notifications@github.com wrote:
|
@@ -21,7 +21,8 @@ source: | |||
- configure.patch | |||
|
|||
build: | |||
number: 0 | |||
number: 1 # [linux] | |||
number: 0 # [win or osx] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not just bump to 1? Seems like it should be ok to have new packages for all of them anyways.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because nothing has changed for those OSes :-) So I wanted to reflect that we're rebuilding PyQt only on Linux.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At least that's the standard practice we follow in Continuum :-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ccordoba12 that approach is fine and one can even argue that it is "more correct." We do not enforce it though b/c of the maintenance burden of following two different build numbers.
So if you want to go that route it is OK. If you do not want to do that it is also fine. As the maintainer that is your call.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I prefer not to split the build numbers, having a build missing on the platforms that your change is irrelevant for is fine IMHO. My reason is because I like to think in terms of "build X fixed problem A" and that's easier to remember than "build X on Windows, Y on Linux and Z on OSX fixed problem A".
Also please re-render with |
Ok, this is (finally) ready! :-) Thanks to all for your patience! |
@ccordoba12 - thanks!! I think this needs to be done for pyside too? (e.g. https://travis-ci.org/glue-viz/glue/jobs/169867900) |
Ok, right, I forgot about it :-p @jschueller, could you bump Pyside's build number to trigger a rebuild for it? :-) Thanks! |
Closes #4