#1949: provide floating branch to "current release" and links to it --------------------------+------------------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Other | Version: development version Resolution: | Keywords: EinsteinToolkit --------------------------+-------------------------------------------------

Comment (by hinder):

There is no "git update" command. You probably mean "git pull". Ignoring SVN, and the fact that we have multiple components, this would be a bit tricky even in a single-git repo setup.

As far as I understand it, our support for upgrading from one release to the next is "wipe out your tree and run GetComponents again", which is very bad already, but a complicated problem to get right with multiple repositories in multiple version control systems, any of which may have local uncommitted or committed changes, or be on different branches to master (this is a problem of a component framework, not really something we have done wrong). This has been the case in all the release notes that I checked.

If we reset the branch to point to the new release, then a "git pull" by a user on the original branch would, if there were backported commits on that branch, attempt to merge the new branch into the old branch. If there were backports, this might lead to conflicts. Even if there weren't, the pulled branch would be a merge, rather than identical to the new release, so this is not really what we want.

"git pull" has never been the right command for upgrading from one release to the next. "pull" means to pull in changes from the remote branch tracked by the current branch. Upgrading to a new release corresponds instead, at the moment, to checking out a different branch. i.e. you would do git checkout ET_2016_11. Assuming no local committed or uncommitted changes, this will do the right thing; the code version will switch completely to the new release. If you have local working copy changes, these will remain in your tree, unless there are conflicts which cannot be merged, in which case you will get conflict markers. If you have local commits, they will disappear from your working copy, since you are moving to a branch which doesn't have them, but they will remain on your old branch. This all seems very reasonable.

If we had a floating release branch, I don't think anything would change. The user would "git checkout origin/currentrelease", and I think this would just work.

Since we don't support updating a tree from one release to the next, the issue of updating doesn't apply in any case. The advantage of Roland's proposal is that we wouldn't have to update websites each time.

#1949: provide floating branch to "current release" and links to it --------------------------+------------------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Other | Version: development version Resolution: | Keywords: EinsteinToolkit --------------------------+-------------------------------------------------

Comment (by knarf):

Replying to [comment:2 hinder]:

If we had a floating release branch, I don't think anything would

change. The user would "git checkout origin/currentrelease", and I think this would just work.

If a user would only use 'checkout', yes. One 'pull' and you might have a great mess. And 'pull' would be the preferred way of updating the release branch to get fixes there. Which would mean that up until the next release 'git pull' is recommended, past that date the same command could be harmful.

Since we don't support updating a tree from one release to the next, the

issue of updating doesn't apply in any case. The advantage of Roland's proposal is that we wouldn't have to update websites each time.

As I understand currently, a moving 'stable' branch would be a nice thing to limit work we need to put into updating documentation, but it would present a problem to some users - especially if we were to use it by default.

I would argue that this tries to solve a problem that really isn't such a big one, with potential for trouble for users. Most of the work for a release isn't updating version strings in documentation and tutorials. We could make that even simpler using, e.g., wiki variables. Most of the work is actually going through these tutorials the way a user would, by hand, to test if they still work that way, that there isn't a typo on the web page, check for out-dated comments, look out for machine or policy changes ect.

#1949: provide floating branch to "current release" and links to it --------------------------+------------------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Other | Version: development version Resolution: | Keywords: EinsteinToolkit --------------------------+-------------------------------------------------

Comment (by rhaas):

This was discussed in the ET call http://lists.einsteintoolkit.org/pipermail/users/2016-August/004937.html and a regular branch seems to be impossible to maintain due to conflicts occurring during git pull if two releases each contain changes the other does not.

A release tag on the manifest would likely work, with the proposed update scheme being: {{{ bin/GetComponents -u --root . https://bitbucket.org/einsteintoolkit/manifest/raw/bf59de8ab5b2dbd11c09bc64f... }}}

If we really want branches and the ability to do a git pull then one would have to update the release branch along these lines:

{{{ git checkout release git diff release..ET_2016_11 | git apply --index git commit -m 'update release branch' git merge ET_2016_11 -m 'merge with new release' }}}

which basically commits a single commit with the difference between releases onto the release branch. Not a very nice solution.

In light of this, a tag on manifest would be better.

#1949: provide floating branch to "current release" and links to it --------------------------+------------------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Other | Version: development version Resolution: | Keywords: EinsteinToolkit --------------------------+-------------------------------------------------

Comment (by eschnett):

This all sounds awfully complicated. Will it, in the end, actually be simpler than telling people to check out a new version? Keeping in mind that people will be careful anyway, and won't want to destroy their current version, but rather checking out a new version anyway for testing? Which they will want to do since there's no good way to go back in time in our {{{GetComponents}}} scheme?

Ensuring that the checkouts have the version number in automatically created directory names might suffice for everybody to be happy.

#1949: provide floating branch to "current release" and links to it --------------------------+------------------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: closed Priority: minor | Milestone: Component: Other | Version: development version Resolution: wontfix | Keywords: EinsteinToolkit --------------------------+------------------------------------------------- Changes (by knarf):

* status: new => closed * resolution: => wontfix