ISIS3 Release Schedule, Release Processes, and Versioning

[jlaura]

This issue runs in parallel with RFC2 and should be used for discussion of the linked RFC.

[jessemapel]

For a little more context about how this relates to ISIS3 right now:

1. The latest release, 3.6.1 was a bug fix release as a test of the proposed versioning process. It does not contain any functional changes compared to 3.6.0 even though there are new functional changes in dev.

2. As stated previously, there are functional changes in the dev branch right now that are not in 3.6.0 or 2.6.1. So, in May, we'll be ticking the version number to 3.7.0.

Here's an incomplete list of new features that are currently staged for release in 3.7.0:

• Support for ingestion of Kaguya Terrain Camera images
• Support for bundle adjustment using rectangular coordinates instead of latitudinal coordinates (BundleXYZ has been the development name for this feature).
• Support for writing bundle adjusted instrument pointing from TGO CaSSIS imagery to smithed Kernels.

[jessemapel]

How should we version custom builds for missions? For example, if we put out a custom build for the TGO CaSSIS team right now with functional changes would it be 3.7.0_cassis or would it be 3.6.1_cassis?

[jlaura]

@jessemapel I think we have a few scenarios to deal with. Before trying to walk through those, what is the lowest friction method to do this? How are thinking about 'back' porting bug fixes into mission branches, or are mission branches snapshots of dev plus feature additions that are not then kept in sync.

Given the short lifetime of mission directed effort between releases, is it worth the effort to keep any non-mission specific bug fixes up to date in the mission branch? In other words:

• mission requests a feature addition
• branch is made from release (or dev?)
• feature is added to the mission branch and the branch is released as version.branched.from_mission
• if feature is also PRed into dev(?) - this suggests that any mission requested effort will (assuming a clean release candidate is built) be released in the next release cycle
• if the mission has another feature addition in the same release cycle, rebranch from dev (?) and repeat the process.

I think I am falling onto the side of current.version.number_mission for versioning, but have questions about the level of effort needed and desired to keep these snowflake releases around between official releases.

[kberryUSGS]

On a different thread than the current conversation, there are the following quotes regarding the purpose of this RFC:

" This RFC does not address the way in which ASC personnel `set isis' within the ASC system."

and

"Additionally, we have identified a misalignment in expectations with respect to the ISIS3 'nightly' and 'beta' releases. This RFC seeks to provide mechanisms to align expectations regarding the creation of nightly builds and the generation of beta releases."

This seems slightly inconsistent to me, in that our nightly and beta releases were only built and available internally within ASC, and would be primarily used via running 'setisis' inside ASC, and this document deliberately doesn't address this internal process. (Right now, I don't think there are non-ASC expectations regarding nightly builds?)

This may only be confusing to someone who is operating from a primarily "ASC internal" standpoint -- nightly and beta builds obviously don't imply solely internal use in general -- but if I found it confusing, someone else may find it confusing, too.

Also -- @jlaura is there a better way to make line-by-line comments for wiki entries in github?

[jessemapel]

@kberryUSGS I think that you're right, internal nightly/beta builds are a separate RFC. I'd change the second line to

"Additionally, we have identified a misalignment in expectations with respect to when and how bug fixes and feature changes will be made available. This RFC seeks to provide mechanisms to align expectations regarding the availability of such changes."

I am currently writing an RFC to deal with internal builds and how ASC users can access different versions of ISIS3.

[jlaura]

@kberryUSGS For the line by line just go ahead and edit the wiki. You should have the privileges.

[jlaura]

I have updated the wiki with the change. @jessemapel Can you hold onto the RFC for internal for a few days. If we can get our internal/external facing discourse server live then we should post this internal RFC to the internal discourse board - the impact of how we access our builds will not impact the broader community.

[rbeyer]

According to the Semantic Versioning 2.0.0 spec, item 9, indicates that the separator between the patch version and any pre-release identifier must be a hyphen. So it would be 3.8.0-RC not 3.8.0_RC.

[SgStapleton]

I just realized that since we are changing how/when we increment our major version, we may consider changing this repo name as well as update (possibly quite a bit of) documentation. We may also want to look into how we are naming our files on Anaconda Cloud. (Do we want users to pull down newer major versions of ISIS by default, or should they have to specify what major version they would like? Either way, the "name" parameter in our meta.yaml needs to be updated either once to "isis" or with each major version to "isis4", "isis5", etc...)

[jlaura]

I am going to motion to close this RC with the following addendum (that I will add to the RFC wiki text):

Addendum to the RFC

• Release Candidates will be versioned using a hyphen, e.g., 3.7.0-RC
• In instances where mission specific builds are necessary they will, going forward use the hyphenated mission name as well.
• The repo will be renamed isis

Accepted from the RFC

• Semantic versioning
• Quarterly release schedule with release candidates
• Incremental bug fixes with a 1:1 fix to bug-version increment (e.g., 3.7.1, 3.7.2, 3.7.3, ...)

I will close this issue on 4.2.2019 and 'merge' the RFC into our processes unless we get feedback / pushback on this RFC. If this sounds acceptable to all contributors / maintainers / readers, can you respond with :+1: or :tada: or another inline 'sounds good'?

[jessemapel]

@jlaura if we change the repo name do we need to track down dead links?

[jlaura]

@jessemapel yes...

Edit - not for people with git clones - somehow git is smart, but all the webpages will break.

[jlaura]

closing as this RFC has been adopted.