[Proposal] Maintaining stable releases

[HashNuke]

There's an increase in fixes happening in the master branch.

• Good thing: there's always updates
• Bad thing: there's always updates

Should we have a separate stable branch and release tags that are merged into the stable branch? So whoever gets the stable branch always gets the latest stable release AND can also pick a tag and use just that.

The above idea above was just an opinion. Open to other ideas to maintain a stable release.

[Stratus3D]

YES! I've been thinking about the fact that we haven't tagged any releases, and that's something I'd like to change as it may help when it comes to handling issues in the future. I like the idea of a stable branch because it would make it easy for people to get the latest tagged release by default.

So our workflow would maybe look something like this?

• Determine what is going in the next release
• Update the version in asdf on master sometime before tagging (https://github.com/asdf-vm/asdf/blob/master/lib/utils.sh)
• Once everything is merged into master, tag the release, then merge it into the stable branch

[HashNuke]

@Stratus3D had the same thing in mind but without the first step (because we dont really know what's going to come next... being very honest :) )

So something like this:

• keep developing on master
• when we decide it's enough for a version, we tag it and make a release
• merge the tag into the stable branch

@tuvistavie opinions?

[danhper]

I totally agree on maintaining stable releases.

I have no strong opinions on the workflow, but what are the
benefits of having a stable branch here?

For reference, in some other project I maintain, I simply tag each release,
have git clone --branch TAG REPO in the install instructions,
and have an update command which basically does

git fetch
git checkout $(git describe --tags) 

[rockwood]

I agree with @tuvistavie on having only a master branch with tagged releases. Maintaining a separate stable branch with tags adds some complexity.

We could create a Homebrew formula that installs the latest tag, and have alternate instructions for non homebrew users. The asdf name is currently available on Homebrew if we want to grab it.

[Stratus3D]

I've tagged the first release (0.1.0) and I've prepared everything for the next release (it has to be 0.2.0 since we have some API changes). I also created a PR that updates the install command in the readme so that 0.1.0 is checked out when asdf is installed. I also created a separate PR that adds a change log, if you all thinks that is necessary.

I think this is all that needs to be done to get the ball rolling for stable releases. From now on when creating a release we just need to:

• Tag the release
• Update the install command in the README on the master branch (so that users see the correct command when they visit the project page).

We can also increment the version number in lib/utils.sh to the next version and a section for the next version to the change log in the master branch(e.g. if you tag say 0.2.0, then you should increment the version in lib/utils.sh to 0.2.1, so that when the next tag happens the version is already correct). Of course we don't necessarily know what the next version will be, so this may be unwise. Thoughts?

[Stratus3D]

Closing this issue since I have merged both PRs. If anyone else has any thoughts or concerns on this please re-open this issue.