Separation between master (default) and develop branch about schism

[brey]

I agree with @jamal919 that having tagged versions (or releases) is important in reproducibility of runs based on SCHISM. Also, in operational settings, a frozen version could be implemented for a long time before various tests and hindcasts allow for an update. The way it is now, one has to tag their forks themselves which could create confusion.

As Joseph mentioned, if the code is indeed functional at any given time, then you should create occasional releases referencing the corresponding new features.

[water-e]

I agree with the issue, but I think we have all the plumbing to so this. Perhaps we could get a start on this by getting a release branch done within 2 days?

There is no need for a change in branch strategies just for stable releases. The strategy we originally vetted, Trunk Based Development (see trunkbaseddevelopment.com) is really fine for that as long as it is fully utilized.

A "stable release" in the TBD model is done in two steps. First, you create a release branch every once in a while and the feature set and interface is frozen but perhaps still honed for a bit. The release branch is a space for curators and maintainers, not for the main development. The release branch is also not a complete release, but rather a "parent" of releases -- it has only the major and minor version number, e.g. 5.9. The actual releases are tags (5.9.0, 5.9.1 etc) are made off this branch. Risky dev continues on master and any bug fix in master that are worthy get an isolated commit and are cherry-picked to the release branch. Release branches are never folded back in to master, and that is their key virtue ... you aren't developing things that require reintegration.

There are other branching styles (checkout GitFlow, GitHubFlow, Trunk Based Development and Branching By Abstraction). The one usually associated with 'develop' is GitFlow. GitFlow is considered the most complex, and that isn't necessarily a good fit for our culture, but I say that in some ignorance ... I have limited experience with one project where it worked out fine but there was someone collecting $100K per year to make it work.

[jreniel]

Hi All, I just want to throw in one small comment. When it comes to versioning on git, the only thing that matters is the commit hash. It is preferable to refer to a version using it's hash than it's semantic versioning number. Tags are merely pointers to specific commits. So if you need a specific version of SCHISM, or you want to keep track of which version you use, you should write down the commit hash. Even tags are not fully a good idea to use as versioning, because tags are mutable. A commit hash will never change and is the only "version number" that really matters in the end. So no matter which git strategy you use, the commit hash is the version number you want to keep track of.

…

-Jaime

On 5/4/20 9:18 AM, George Breyiannis wrote: I agree with @jamal919 <https://github.com/jamal919> that having tagged versions (or releases) is important in reproducibility of runs based on SCHISM. Also, in operational settings, a frozen version could be implemented for a long time before various tests and hindcasts allow for an update. The way it is now, one has to tag their forks themselves which could create confusion. As Joseph mentioned, if the code is indeed functional at any given time, then you should create occasional releases referencing the corresponding new features. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#14 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEXYQTTBCQWZMIYR4EGRQJ3RP26BVANCNFSM4MYVBCQA>.

[water-e]

This is a good point, but a tag is almost like a hash ... Jaime pointed out it is really a commit an mutable, but this is esoteric compared to our current woes. At DWR we like having the occasional anointed version number we could describe over the phone, although there are times we've saved ourselves with a full hash when it wasn't a tag and you don't have to have the agreement of the community. Plus it is perfectly unambiguous.

There are good reasons for semantic version numbers. I like knowing the sequence of tags 5.10.1, 5.10.2 is a "feature frozen" set and hashes, while great as ID numbers, don't convey organization of the work.

[jreniel]

The tag is not a hash. The tag is completely mutable. Only the hash is immutable. But tags are useful, though. ⁣Sent from BlueMail ​

…

On May 4, 2020, 15:01, at 15:01, water-e ***@***.***> wrote: This is a good point, but a tag is a hash and also unique. We like having the occasional anointed version number we could describe over the phone, although there are times we've saved ourselves with a full hash when it wasn't a tag and you don't have to have the agreement of the community. There are good reasons for semantic version numbers. I like knowing the sequence of tags 5.10.1, 5.10.2 is a "feature frozen" set and hashes, while great as ID numbers, don't convey organization of the work. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #14 (comment)

[jamal919]

Thanks all for participating in this discussion. I am happy with the direction we are going finally adopting a branching strategy for named versions. Since Joseph just posted the v5.8 branch, I will consider this issue to be resolved and close it. Thanks again to all.

[josephzhang8]

Thank you Jamal for bringing this issue to our attention.

…

-Joseph Y. Joseph Zhang Web: schism.wiki Office: 804 684 7466 From: Jamal Uddin Khan <[email protected]> Sent: Thursday, May 7, 2020 5:38 AM To: schism-dev/schism <[email protected]> Cc: Subscribed <[email protected]> Subject: Re: [schism-dev/schism] Separation between master (default) and develop branch (#14) Thanks all for participating in this discussion. I am happy with the direction we are going finally adopting a branching strategy for named versions. Since Joseph just posted the v5.8 branch, I will consider this issue to be resolved and close it. Thanks again to all. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#14 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AFBKNZ76SSGFABG4LOXT2L3RQJ6QJANCNFSM4MYVBCQA>.