MiGrid workspace where master branch is kept strictly in sync with SF upstream svn repo. Any development or experiments should use a branch. You probably want to fork your own clone or work e.g. on the edge branch if you wish to contribute.
With the edge branch practically in production on our own core long-running production sites and the on-going migration to experimental everywhere with python3 as default we should really get rid of those outdated and misleading branch names.
We have discussed renamingexperimental to next and edge to the github default main plus make the latter the default branch in clones. We need to preserve backwards compatibility in relation to the branch names in docker-migrid envs etc. so the renames either means clone and alias them to the old names or preserve those old branches and sync back changes there for a while. That sync should be possible to do automatically with a github action.
That will additionally allow us to merge next into main at some point when we decide to completely switch to python3. If needed we can make a legacy branch copy at that time and keep it around for extended support.
While at it we should also adjust releases and tags here to specifically point at one of those branches rather than master. Otherwise it's not obvious for admins of partner sites not using the master branch how to obtain and use a matching git revision for a given release / tag.
A proposed solution would be to use Main-YYYYMMDD / v2.x and Next-YYYYMMDD / v3.x respectively for new such releases / tags pointing to those branches specifically in line with the Stable-YYYYMMDD / v1.x we have used so far pointing to master.
With the
edgebranch practically in production on our own core long-running production sites and the on-going migration toexperimentaleverywhere with python3 as default we should really get rid of those outdated and misleading branch names.We have discussed renaming
experimentaltonextandedgeto the github defaultmainplus make the latter the default branch in clones. We need to preserve backwards compatibility in relation to the branch names indocker-migridenvs etc. so the renames either means clone and alias them to the old names or preserve those old branches and sync back changes there for a while. That sync should be possible to do automatically with a github action. That will additionally allow us to mergenextinto main at some point when we decide to completely switch to python3. If needed we can make alegacybranch copy at that time and keep it around for extended support.While at it we should also adjust releases and tags here to specifically point at one of those branches rather than
master. Otherwise it's not obvious for admins of partner sites not using themasterbranch how to obtain and use a matching git revision for a given release / tag. A proposed solution would be to use Main-YYYYMMDD / v2.x and Next-YYYYMMDD / v3.x respectively for new such releases / tags pointing to those branches specifically in line with the Stable-YYYYMMDD / v1.x we have used so far pointing tomaster.