bash-it update to stable or dev

[NoahGorny]

Part of solution for #1500

we will need to push a tag someday 😄

[NoahGorny]

what do you say @nwinkler ?

[nwinkler]

Which one should we look into getting completed first? This one or the one with the silent flag? #1621

[NoahGorny]

I think we should rebase #1621 on top of this, CR it first and then move on and CR this one. We could then merge #1621 into this and then merge this.

What do you think?

[nwinkler]

Like you said above, we'll have to create a release/tag at one point, so that the stable parameter actually does something. Maybe we just (manually) create a release called 2020.07 and use that. I like the idea of doing monthly releases - I know it's not exactly semver-like, but it avoids having to think about major/minor versions...

Thoughts?

[NoahGorny]

Like you said above, we'll have to create a release/tag at one point, so that the stable parameter actually does something. Maybe we just (manually) create a release called 2020.07 and use that. I like the idea of doing monthly releases - I know it's not exactly semver-like, but it avoids having to think about major/minor versions...

Thoughts?

I am positive on releasing monthly, but why not use semver-like versions?
We can create v1.0.0 tag, and bump the minor in the monthly release. In case of bug fixes, we can bump the patch version.
We do not have to create a thoughtful discussion every time we want to bump, and creating "news" overview or changelog should not take too much of our time (I can take responsibility if needed)

In a sidenote, maybe we should continue on #1500 and reach a consensus with more people, so we will fill okay with this decision

[nwinkler]

Looking good! Just a couple of minor comments...

And of course we need to figure out the tagging question (#1500).

[nwinkler]

Great, this looks like it's ready for merging - now we just need to create a tag so people have something to update to.

That might be a concern: So far, bash-it update has always updated to the latest version of the repo, similar to what's now the bash-it update dev behavior. With this PR, we're now changing this to default to the latest tag (with the stable parameter) - this might feel strange to existing users, who are used to getting the latest and greatest version.

Does it make sense to show this more prominently? For example when you run bash-it update (and it assumes the stable version is wanted), that we show a message saying "You're on the latest stable version. If you want to check out the latest 'dev' version, please run bash-it update dev"? At the moment, we just show the generic "Bash-it is up to date, nothing to do!" in that case...

Sorry for the continued back and forth, I really want to get this right. I know that quite a few people are using bash-it update, and I don't want to break their user experience.

[NoahGorny]

You're on the latest stable version. If you want to check out the latest 'dev' version, please run bash-it update dev

This is a good idea, I added a message in this case. (see 2a971f0)
I do think we need to push out a tag now, and then we can merge this (or after merging, or both!).
I also think that its okay that we change the default behavior here as the default option should be a stable release!

[NoahGorny]

@nwinkler I added a new commit (20670fb) that moves git fetch --tags to be before tag calculation, as otherwise we could not update..

[nwinkler]

OK, this looks good to me, thanks! Let's continue the discussion on adding the tag, and then we can merge this.

[NoahGorny]

Hey @nwinkler, I think we are ready to release a starting version as we discussed and merge this!

[NoahGorny]

@nwinkler @cornfeedhobo @davidpfarrell I think it is time for us to merge this and release our first tag!
I added an important check if you are updating to a stable version but you have a more updated dev version. It will now warn you and continue (to ask you/just do it in silent mode)
What do you guys think?

[NoahGorny]

Time for v1.0.0 🎉