Tagging convention - Githubissues

rendinam commented 5 years ago

@oiintam , is the latest tag supposed to be 1.4rc1 given that the previous release was 2.3.0?

oiintam commented 5 years ago

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.

rendinam commented 5 years ago

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.

vglaidler commented 5 years ago

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:

treat it as a Pandokia release, tagging it as 2.3.1, or
prefix it as pandeia_1.3rc1 (even though that breaks symmetry with the tag used in pandeia).

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

oiintam commented 5 years ago

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. Thank you.

vglaidler commented 5 years ago

@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.

rendinam commented 5 years ago

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 2.4.0 tag had been made, but it has subsequently been removed. A tag of that type would be appropriate, as long as it is a monotonic increase in value from existing tags to prevent confusion and to allow dependency resolution to function.

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. pandokia.__version__ will reflect the tag name that is associated with the commit being installed. If a tag is not defined, this version information is derived from git describe and will contain a dev signifier which would not be appropriate for inclusion in the official-release conda packages hosted on the Astroconda channel.

If a version tag > 2.3.0 could be applied to the commit desired for release, the rest of the packaging process should be painless.

vglaidler commented 5 years ago

Sent out calendar invites for a webex discussion tomorrow at 3:30

vglaidler commented 5 years ago

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.

And/or, associate the branch name for a release with a revision. Then we could use the revision. (IE, do what tags do but without actually using tags so as to avoid conflicting with HST practice.) JWST logic is that we don't need a release of Pandokia; we're willing to release pandeia based on a revision/branch that doesn't correspond to an actual Pandokia release. Rationale: gives us more flexibiity. It's also true that the effort of moving to a new third party is much larger on the JWST side than it is on the HST side. We're not really making public releases except pandeia.engine.

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.

spacetelescope / pandokia

Tagging convention #56