Separation between master (default) and develop branch #14
Comments
|
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. |
|
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. |
|
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>.
|
|
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. |
|
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)
|
|
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. |
|
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 <notifications@github.com>
Sent: Thursday, May 7, 2020 5:38 AM
To: schism-dev/schism <schism@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
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>.
|
In the SCHISM repo, all new modifications are added to the master branch directly (like svn). As
masterbranch is also thedefaultbranch. It means anytime someone is trying to use the model - she/he will get a different version of the code for eachgit clonecommand.In many other community model I have noticed that they manage a so called
developbranch for continuous integration of the new developments and keep themasterbranch frozen till the next release. For example NOAA-WW3 model - https://github.com/NOAA-EMC/WW3Given the user community of SCHISM is growing out from modellers to users, I propose that after the next big release, we also reorganize the development in this fashion so that the typical
git clonecommand yields the same version of code (effectively last release version till then) until the next release comes out.The text was updated successfully, but these errors were encountered: