Semantic versioning about labeler HOT 5 CLOSED

Hi, @illrill I'm basically keeping a simplified schema without the patch version for no particular reason. I generally bump the minor as I intentionally avoid breaking changes (e.g. I did introduce a different configuration format a while back, but ensured that the action would still support old files). If I do one, I would indeed bump the major.

In any case, I'm fine with using a full semver string if that makes things clearer downstream. I will republish the latest version as 1.4.0 and follow from there.

Thanks!

from labeler.

Thanks for the feedback!

Actually the main concern I had was around what would happen after 1.9 - I just assumed it would automatically hit 2.0 even if there's no major/breaking change. But perhaps I assumed too much, now that you explained it... It would become 1.11, wouldn't it? If that's the case, it's fine as-is for me.

The background to why I care is that the administrators of our Github Enterprise organization has a rule that they need to approve and "whitelist" each major version of all open-source actions. So when we reach version 2.0, I'll need to go through the hoops of requesting the admins to re-whitelist srvaora/labeler@2.* 😄

from labeler.

BTW, the organization I consult for is H&M Group, so this piece of software is used by a quite large company 🥇 💪

from labeler.

Yeah, I think you summarize the point quite well. I originally didn't want to overcomplicate the versioning part but at the point this is used by orgs with minimum supply chain controls standards will actually save time.

I expect we'll stay on 1.x for a fair amount of time.

Thanks a lot for the feedback and happy to see this is useful to you at H&M!

from labeler.

Closing but let me know if I there are any loose threads there!

from labeler.