provide floating branch to "current release" and links to it

Issue #1949 open
Roland Haas created an issue

In order to not always have to update all websites with the correct ULRs to the then current release it would be good if we were to provide a "current release" branch of the ET which always points to the head of the current release branch/tag. Ie right now it would be identical to 2016_05.

Keyword: EinsteinToolkit

Comments (11)

  1. Frank Löffler
    • removed comment

    Good idea in principle. One would need to think about how to provide an update path then. Because once we start using a 'stable' branch, people will expect to be able to 'update' it (git/svn) for a new release. That not only breaks because repos might have been added or removed, but we would need to think how to provide a 'stable' branch that doesn't break on 'update', even with possible local changes.

    Another question would be that we would add confusion what, say, 'git update' does. On an ET_XX branch it would pull critical updates. On 'stable' (which might have been idential to ET_XX at some point) it would eventually pull in updates from a new release on 'git update', which might be unintentional.

  2. Ian Hinder
    • removed comment

    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.

  3. Roland Haas reporter
    • removed comment

    I think the update strategy would then be:

    bin/GetComponents -u --root . .crl_components # update manifest
    bin/GetComponents -u --root . manifest/einsteintoolkit.th # update everything else
    

    which should work with the current setup. I would actually argue to remove the complex logic about preserving changes and doing git stash etc in the git code of GetComponents and use a simpler strategy: "if the workspace is clean and git pull --ff-only succeeds use this otherwise use the result of git fetch only and inform the user that repo XXX could not be updated due to local changes".

  4. Frank Löffler
    • removed comment

    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.

  5. Frank Löffler
    • removed comment

    What I could imagine is a moving 'stable' branch only for the manifest repository. That way, GetComponents calls would always pick up the current stable version, but within the thornlist the current version string would be used. Local repositories (even the manifest repository) would only use the ET_XXX branch names.

    Instead of

    ./GetComponents --parallel https://bitbucket.org/einsteintoolkit/manifest/raw/ET_2016_05/einsteintoolkit.th
    

    we would have

    ./GetComponents --parallel https://bitbucket.org/einsteintoolkit/manifest/raw/stable/einsteintoolkit.th
    

    without any change of that thornlist.

  6. Roland Haas reporter
    • removed comment

    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/bf59de8ab5b2dbd11c09bc64f26f886ad1f40e56/einsteintoolkit.th
    

    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.

  7. Roland Haas reporter
    • removed comment

    Barry suggests using an actual git workflow for this. As far as I can understand this gives a release branch (the master branch in the example provided in http://lists.einsteintoolkit.org/pipermail/users/2016-August/004942.html) that would look a bit like the "release" branch in the "git-apply" example above, only that the updates are done via git merges. Conflicting commits in release and development are resolved by merging the release branch back into development (and then most likely ignoring the release half of the merge). Hotfixes on the release branch (master) are merged back into the development branch (https://www.atlassian.com/git/images/tutorials/collaborating/comparing-workflows/gitflow-workflow/05.svg) and again if the release branch required a different fix for the issue than the development branch, then the release branch half would be dropped in the merge.

    The hotfix issue is interesting for us since typically we will find a bug in the release code while reworking a section of code to add a new feature. This often means that the fix for the bug in the development branch (with half a feature added or due to whitespace changes of various sorts) does not apply to the release branch so we have to provide a separate fix for the release branch.

    So the gitflow workflow would do what we want and would only require a modest amount of extra work during the release cycle (and we are free I guess to call our branches "release", "master", "ET_2016_05" rather than "master", "develop", "ET_2015_05" I guess).

  8. Erik Schnetter
    • removed comment

    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.

  9. Ian Hinder
    • removed comment

    I agree that it is too complicated; Barry was not proposing it, just mentioning it. It's especially much too complicated when we have a component framework with multiple repositories to keep track of.

  10. Log in to comment