I have a suggestion for how drupal.org could use git in a way that would make it far more convenient to follow the latest release: add a separate branch that contains only releases, e.g. only 7.x releases.
At the moment, the structure of drupal.org git repositories is such that all development on the next 7.x release happens on the "7.x" branch. When that development has completed, the latest commit on that branch gets a tag with its version number (e.g., "7.13"), which marks the release, and development then continues on that same branch. This means that anyone who wants to follow the latest release first has to look up the latest tag and then do a checkout on that tag.
Would it not be much more convenient if there were separate "7.x" and "7.x-dev" branches, the former for releases and the latter for development? Then, whenever development on the "7.x-dev" branch has reached maturity for a new release, the release is performed by merging "7.x-dev" into the "7.x" branch (plus still adding a tag like "7.13" to the result of that merge, to document the version number). This way, those of us who merely want to keep our production environments up-to-date with the latest release simply would have to initially do a "git checkout 7.x" to get the latest released 7.x version. After we have specified this way once what we want, we simply have to type "git pull" every now and then, to update to the very latest released 7.x version.
Any particular reason why that isn't done?
Having such release branches would seem much more convenient (especially in scripts), than having to manually specify the latest release tag each time. It would also make it easier to merge new releases into a local branch, which could simply track the 7.x release branch.
Comments
Comment #1
helmo commentedChanging this naming convention would be a huge undertaking. Not only for core, but also for contrib.
I can see your point though.
I see a two options:
We might even be able to automate that in the packaging scripts.