Tag & branch names

[ioquatix]

I'd like to propose we tidy up our branches and tagging strategies. I think we can standardise on the same model as rails. It's similar to our recent branches but tags should include a v prefix going forward.

I'm open to ideas about stable branch naming conventions, but I don't see a big advantage over what we are currently doing, although I do prefer stable-vx.y over x-y-stable which always felt backwards to me.

[jeremyevans]

For tags, I prefer the actual version without the v prefix (what we currently do, other than 2.2.1 and 2.2.2). For branches, I think the current naming conventions are fine. I don't think there is any advantage in changing in the current branch/tag naming scheme.

[ioquatix]

I looked at a couple of gems, rspec, bundler, rails, rake, tzinfo, all of them follow the v prefix convention. I think we should follow it too going forward.

Yes, it's important to be internally consistent, but it's also important for popular gems to set a good and consistent example for the wider community. Additionally, release management tooling is likely to follow this same convention. Right now we have a bunch of rake tasks for doing this, but every other gem I'm working on is using standard tooling. Adopting the standard approach will make release management easier and consistent across the entire org.

Non-v prefixed release tags:

• rack

v prefixed release tags:

• rackup
• rack-session
• rack-attack
• rack-contrib
• rack-test

And if I had to take a guess, I'd say probably 90%+ of other Ruby gems.

[jeremyevans]

I looked at a couple of gems, rspec, bundler, rails, rake, tzinfo, all of them follow the v prefix convention. I think we should follow it too going forward.

I disagree. All of my libraries use the unprefixed version, since that's the simplest approach. However, I still used the v prefix for tags in rack-test, because that's what the library used, and I think it's more important to be internally consistent than to follow the fashion of other libraries (even my own libraries).

If you want a technical argument, there's always the argument for efficiency. Usage without v prefix is probably over 15% more efficient from a typing perspective. :)

Yes, it's important to be internally consistent, but it's also important for popular gems to set a good and consistent example for the wider community.

I don't think the use of a v prefix is a better example than a plain version number. Merely a choice that some/most other gems happen to follow. You may think both are important, but I think being internally consistent is far more important.

Additionally, release management tooling is likely to follow this same convention. Right now we have a bunch of rake tasks for doing this, but every other gem I'm working on is using standard tooling. Adopting the standard approach will make release management easier and consistent across the entire org.

Having never done a rack release, I'm not sure what "release management tooling" is used or needed. I don't use any sort of tooling for any of the other gems I maintain, mainly because the process is so simple that I don't need to use tooling (nothing wrong with tooling if you need it, though).

Non-v prefixed release tags:

• rack

v prefixed release tags:

• rackup
• rack-session
• rack-attack
• rack-contrib
• rack-test

And if I had to take a guess, I'd say probably 90%+ of other Ruby gems.

Argumentum ad populum does not sway me much.

[ioquatix]

Consistency within the repo or consistency with the organisation? Well, as long as you are happy to be inconsistent at the org level...

That being said, tag names are cheap, I'm not concerned about memory usage, but clarity in what the tag means. If internal consistency is important, we can literally rewrite all the tags.

[jeremyevans]

Consistency within the repo or consistency with the organisation? Well, as long as you are happy to be inconsistent at the org level...

Tags are per repository, not per organization, so obviously internal consistency refers to tags for a single repository.

That being said, tag names are cheap, I'm not concerned about memory usage, but clarity in what the tag means.

I don't think v2.2.2 is more clear than 2.2.2. It's obvious in either case that it relates to version numbers.

If internal consistency is important, we can literally rewrite all the tags.

That would break use of existing tags for no benefit (e.g. Gemfile with :tag option)

[simi]

What's the benefit?

[ioquatix]

1. Set a high bar for a popular repo to follow established conventions (i.e. if people look at rack as an example of best practice).
2. Allow us to use standard tools for release management like bundler/gem_tasks.

[jeremyevans]

1. Set a high bar for a popular repo to follow established conventions (i.e. if people look at rack as an example of best practice).

I don't think what we currently do is a lower bar, and I don't think switching tagging formats somehow increases the height of the bar.

2. Allow us to use standard tools for release management like bundler/gem_tasks.

Do we plan to use this? What benefit would it bring? Looking at the tooling, I'm not sure we would want to use it. For example, it combines git push with git push --tags. I consider it a best practice to not push the tag until CI is passing for the commit, as you wouldn't want to tag a failing commit, right? Even if for some reason we wanted to use this tooling, it's not hard to override one method (https://github.com/rubygems/bundler/blob/35be6d9a603084f719fec4f4028c18860def07f6/lib/bundler/gem_helper.rb#L170-L172).

To sum up, you've made your point about consistency with other gems. You understand your request is inconsistent with what has been done historically in the library. You know that I'm against the change, so if you want this changed, please try to convince @tenderlove .

[tenderlove]

Let's stick with what we have please. I don't see any reason to change

…

Sent from my iPhone

On Aug 5, 2022, at 3:01 PM, Jeremy Evans ***@***.***> wrote:  Set a high bar for a popular repo to follow established conventions (i.e. if people look at rack as an example of best practice). I don't think what we currently do is a lower bar, and I don't think switching tagging formats somehow increases the height of the bar. Allow us to use standard tools for release management like bundler/gem_tasks. Do we plan to use this? What benefit would it bring? Looking at the tooling, I'm not sure we would want to use it. For example, it combines git push with git push --tags. I consider it a best practice to not push the tag until CI is passing for the commit, as you wouldn't want to tag a failing commit, right? Even if for some reason we wanted to use this tooling, it's not hard to override one method (https://github.com/rubygems/bundler/blob/35be6d9a603084f719fec4f4028c18860def07f6/lib/bundler/gem_helper.rb#L170-L172). To sum up, you've made your point about consistency with other gems. You understand your request is inconsistent with what has been done historically in the library. You know that I'm against the change, so if you want this changed, please try to convince @tenderlove . — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.

[ioquatix]

Fair enough. Can you please document the release process, i.e. "what we have"? Because I'm not sure what we are using in the Rakefile or what we aren't. The gem tasks we pull in add a v prefix, but we aren't doing that according to the tags we have in the repository. Are you tagging it manually?

i.e. if I go into the rack gem right now and run rake release I get:

> rake release
rack 3.0.0 built to pkg/rack-3.0.0.gem.
Tagged v3.0.0.

When I did some 2.x releases, I used the rake tasks we have setup, i.e. rake release, which generates tagged releases with a v prefix, but some how your are making releases without this format. It would be great to have this process documented (if it isn't already).