You don't seem to be using release numbers in the way they're meant to be used.
The release notes for site_banner 7.x-4.0 (https://www.drupal.org/node/2251999) say:
> Some minor fixes and documentation improvements
That should not be a new major release number! The format is CORE.x-MAJOR.MINOR, so a release that has minor improvements on 7.x-3.0 should be called 7.x-3.1. In general, you should only increase the MAJOR if your new release has sweeping changes that affect compatibility with earlier releases.
Comments
Comment #1
ajosephau commentedThanks for picking that up - I struggled to learn Git and it's tagging system coming from an SVN background... ideally I just wanted that latest version to be version 1.0 but that didn't seem to work.
I'll try again to make some more sensible tags: for the record I was following the advice at:
Comment #2
ajosephau commentedOK so it's probably not the most elegant of all solutions, but considering I can't remove those old tags I thought I might create a new tag 7.x-1.1 on the current HEAD revision and publish that node. I'll hide the 7.x-4.0, 7.x-3.0 and 7.x-2.0 revisions so there's just the 7.x-1.1 and 7.x-1.x developer versions on the main page...
The 7.x-1.1 version is now published on the main Site Banner project page and I've hidden the 7.x-4.0 build from view.
I'll close this issue for now, but if you feel this is not a good way forward please reopen the issue. And thank you for your advice!
Comment #3
joachim commentedI'm not sure that's the best way forward!
My site is now reporting that the 7.x-4.0 I installed is no longer supported, BUT that the latest version IS 7.x-4.0.
Now that your version numbers are that high, I think you're just going to have to keep going with them, and declare the 4.x branch the current branch, and make future releases be 4.1, 4.2, etc.
Comment #4
ajosephau commentedYipes! That's not good.
I agree with you - that's a good course of action. I've done what you suggested, and I'll keep your comments in mind when making future releases.