handle version tag

[mh-cbon]

Hi,

I d like very much it also handles tags
to detect repository that are currently in
RC state such as beta / alpha,
so that i can have better overview of which repo has pending release.

As example i have this repo here (https://github.com/mh-cbon/emd/releases)
with pending release for +10 days, likely i will forget about it if i m into some rush.

Would a patch using Masterminds/semver suitable for you ?

[dmitshur]

Hi, thanks for proposing this enhancement. I want to understand this better, so I have some questions.

I d like very much it also handles tags
to detect repository that are currently in
RC state such as beta / alpha,
so that i can have better overview of which repo has pending release.

Can you describe it in a little more detail please?

What is beta, alpha and how is that determined from tags?

Give an example of various repository states, and what you'd want gostatus to tell you about them.

As example i have this repo here (https://github.com/mh-cbon/emd/releases)
with pending release for +10 days, likely i will forget about it if i m into some rush.

Is it about the number of commits that are on default branch compared to the latest semver tag? How did you calculate the 10 days number?

[mh-cbon]

Hi, thanks for quick feedback!

When i do software, unlike go std practice,
i tag the VCS to give a chance to
the end user to easy refer a software status that works for him.

The tags i create are always following semver specs, so i end with

git tag | semver -sort
- 0.0.1
- 0.0.2
- 0.0.3
- 0.0.4
- 0.0.5
- 0.0.6
- 0.0.7
- 0.0.8
- 0.0.9-beta
- 0.0.9-beta1
- 0.0.9-beta2
- 0.0.9-beta3
- 0.0.9-beta4
- 0.0.9-beta5
- 0.0.9-beta6
- 0.0.9-beta7
- 0.0.9-beta8
- 0.0.9-beta9
- 0.0.9
- 0.0.10-beta
- 0.0.10

When I bump the package either it goes to a patch|minor|major new version, or it goes into a prerelease (a Release Candidate).
Those RC are denoted with the -beta/-alpha suffix.

So i do those RC because i know the software is into some state that needs further validation from my end user, so i publish that RC and wait until i have setup a test to replace end user feedback, or got a feedback to tell me that this is newly wrong.

Thus, sometimes i might change the software, put an RC, then move on other tasks, and possibly forget about the pending RC.

That is as gostatus is smart enough to browse my repo, talk with the VCS, it seems the good fit to have an overview of my repo that might be in pending RC, as much as not pushed commits etc.

Desired output is not extraordinary,

$ gostatus all
  +  github.com/dchest/uniuri/...
	+ Pending RC

or similar.

Is it about the number of commits that are on default branch compared to the latest semver tag? How did you calculate the 10 days number?

When i posted about it nop, it was just the value provided in github in the release page see https://github.com/mh-cbon/emd/releases/tag/0.0.10-beta

Its a data that can be extracted from the vcs, indeed, but i m not interested by that information while checking the overview of the repos.

hth

[mh-cbon]

to be precise, semver does not enforce that the metadata (suffix) is beta/alpha, it can be anything in fact.

The scheme i use it not a rule, just something that works for me.

For that ticket its about checking if the last version has a metadata / or not. that s all, in fact.

[dmitshur]

I see, thanks for elaborating.

Desired output is not extraordinary,

$ gostatus all
  +  github.com/dchest/uniuri/...
	+ Pending RC

or similar.

The + symbol is currently used to display when the remote has newer commits that your local repo doesn't have. The - symbol is used to display when the local repo has unpushed commits that the remote doesn't have. So, a minus symbol would be more logical than a plus. However, I'm not sure if it's a good idea to reuse an existing symbol for different things. Unless you want to combine it somehow.

Next Steps

One of my biggest concerns with a change like this is whether or not it's general. I want the status properties that gostatus returns to be general and applicable to all users. It should be as if it's one of the standard go get, go install, go test commands.

I currently rely heavily on gostatus to tell me which of my projects are a work in progress or in an unclean state. I don't actively use tags. So, as I understand, the output of gostatus -c all would change from displaying only a few unclean repos to display all repos, which would be highly undesirable. We could try to hide it behind a flag, but that adds complexity.

Since you know best about what you want out of this feature, I think the best way to move forward is for you to fork gostatus and implement the feature, as you'd like to see it, in your fork.

Then, you're welcome to use your fork for your needs. Once this feature is ready and if you feel it's general enough that it can belong in my fork, then we can discuss potentially merging it upstream.

Does that sound reasonable?

[mh-cbon]

just one question, do you use tags or not ?

can t figure out that one, I don't actively use tags. ... the output of gostatus -c all would change ... to display all repos

besides, what i describe nothing less than the regular go release process, imho.

And i feel ashamed you felt you needed to produce that much of cake to simply say you was not interested.

thanks for feeback whatsoever, i anyway intended to fork it, i only need to check the code at first, that is still undecided, in all cases i want to believe i can find some support into it for my own purpose.

[dmitshur]

just one question, do you use tags or not ?

As I said in #42 (comment), I don't actively use tags at this time.

what i describe nothing less than the regular go release process, imho.

As I understand, tools like dep are still in active development and the practices are evolving. I'm not sure if this is considered a regular Go release process yet, but you're right, things do seem to be headed that way. That's like I'd like to support this if it can be done in a reasonable way.

And i feel ashamed you felt you needed to produce that much of cake to simply say you was not interested.

I'm sorry, I don't understand what you mean, can you clarify? What cake are you referring to? I don't think I said I wasn't interested.

I just pointed out that at this point it makes more sense for you to be able to prototype this change independently, without blocking on me. Given I don't use tags, it's hard for me to provide useful feedback. When you think the feature is in a ready state, I'm happy to evaluate how well it fits into this project.