-
Notifications
You must be signed in to change notification settings - Fork 4
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
Tagging convention #56
Comments
Sorry for the confusion, that tag is meant to be used by JWST ETC. I have changed the title of the pre-release and have consulted with @cslocum . We believe that HST ETC can have an another tag and the naming conversion can be by your standard. Sorry for the inconvenience. |
Shouldn't the tagging convention be local to this project alone? I'm not sure why projects that have a dependency on this one would have any influence on how this project gets tagged and released. A self-consistent feature set that has been tested and validated for release would then receive the next sensible version value and be released. Tagging this project as 1.4 when a 2.3.0 already exists in the wild doesn't seem to make sense. |
Historically for pyetc, we created branches (not tags) in dependent packages like pandokia and pysynphot that had the same branch name so that the script that checked out all necessary code would be able to use the same name. This name was prefaced with the primary project name, eg, pyetc_25.1. It was not used in the context of releases for the dependent project, and this allowed us to I agree with @rendinam that there should not be a 1.3rc1 tag on this project. If we need to tag it, then we should either:
However I'm not up on the implications for the pandeia build tools, so let's see if we can all tag up by phone later today to sort this out. cc @cslocum @oiintam |
I have asked @cslocum about this issue, she is in the middle with ITSD to define JWST ETC firewall related issue. But she said if we can discuss this in our tagup or a meeting since she has opinion and want to express and discuss about it. |
@rendinam after talking with @oiintam and @cslocum this morning, we concluded that while our tools depend on branch names, there are no tools that rely on the tag name, so we will delete this tag and pre-release. Does that address your concerns? We should however still meet to discuss branch & tagging conventions across both ETC projects, sometime in the next few weeks, to make sure we're all on the same page. This probably also affects the glitch-related work in https://jira.stsci.edu/browse/HETC-117. So let's keep this ticket open til then. |
In order to correctly release this project and allow re-packaging with conda, a tag conforming to the semantic versioning standard will have to exist to represent the commit being released. Yesterday, I noticed a Additionally, the tag information gets baked into the python package itself at installation time, so it ends up being an integral part of the python package internals. I.e. If a version tag > |
Sent out calendar invites for a webex discussion tomorrow at 3:30 |
From 2019-04-17 meeting: JWST can rely on branches with branch names in Pandokia. The branches would need to stay around in order to reproduce the same version. IE these would be release branches (even tho we would not necessarily do an actual release) that would persist.
HST will rely on monotonically increasing tags and doing actual releases (github releases as well as external releases) of Pandokia which are then incorporated into HST third party. We could have different classes of tags using different naming patterns. (eg, pandeia_1.3rc1 tag instead of just a 1.3rc1 tag). JWST could modify tools to check out based on tag. For now, JWST will use branch names in this repo while HST uses tags. |
@oiintam , is the latest tag supposed to be 1.4rc1 given that the previous release was 2.3.0?
The text was updated successfully, but these errors were encountered: