Skip to content

Commit

Permalink
Removing leftover/temporary change
Browse files Browse the repository at this point in the history
  • Loading branch information
@BenedekFarkas
BenedekFarkas committed Dec 20, 2022
1 parent f0a2c2a commit aa7599d
Showing 1 changed file with 0 additions and 1 deletion.
1 change: 0 additions & 1 deletion .github/workflows/test-analysis-failure.yml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,6 @@ on:
jobs:
call-test-analysis-failure-nuget:
name: Test Analysis Failure - NuGet PackageReference
if: false
uses: Lombiq/GitHub-Actions/.github/workflows/test-analysis-failure.yml@dev
with:
machine-types: "['ubuntu-latest', 'windows-latest']"
Expand Down

7 comments on commit aa7599d

@Piedone
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@BenedekFarkas with prerelease tags follow https://lombiq.atlassian.net/wiki/spaces/DEV/pages/786857987/Managing+releases+of+open-source+projects

@BenedekFarkas
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@BenedekFarkas with prerelease tags follow https://lombiq.atlassian.net/wiki/spaces/DEV/pages/786857987/Managing+releases+of+open-source+projects

Which part are you referring to?

@Piedone
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://lombiq.atlassian.net/wiki/spaces/DEV/pages/786857987/Managing+releases+of+open-source+projects#:~:text=When%20publishing%20a%20pre%2Drelease%20version

@BenedekFarkas
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you asking about the version number (1.2.0 seems legit for the functional change) or alpha vs. beta? Beta is also valid in semantic versioning.

@Piedone
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Both. This should rather be v1.1.1-alpha.0.osoe-482. We need this to be a patch version increment so whatever we publish as a release version after that will be greater. It also needs to be marked as alpha, since it's not on dev, there's no release notes, and generally, it's something a third-party shouldn't use.

@BenedekFarkas
Copy link
Member Author

@BenedekFarkas BenedekFarkas commented on aa7599d Dec 20, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see - I thought I had an understanding how our wiki extends semver, but here's my thought process:

  1. The next version will be 1.2.0. Actually, since adding a new analyzer is a breaking change, it might need to be a new major version instead of minor?
  2. We need this to be a patch version increment so whatever we publish as a release version after that will be greater.
    Is that because of how NuGet treats the packages? According to semver, 1.2.0 is greater than 1.2.0-beta.0.osoe-482. And generally, how versioning works is that the suffixes are attached to the upcoming final release's version number (i.e., what it will become, not what it's built upon).
  3. It also needs to be marked as alpha, since it's not on dev
    AFAIR there's no rule that would suggest this, only the other way around (if it's alpha, then it cannot be on dev). In general, alpha means "work-in-progress and can be unstable", beta means "mostly stable, but can still have bugs". I used beta, because it was supposed to be the last release before it's merged (except for the small change that came later) - I actually disabled the NuGet test build so I don't have to deal with earlier (alpha) pre-releases while the target is moving.
  4. there's no release notes
    v.1.0.0 and v1.0.1 doesn't have either.
  5. generally, it's something a third-party shouldn't use.
    I can't do anything about that, since the package release is also public.

@Piedone
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. The next production version we release for the project might not be what's in your branch. If we release a v1.1.1 before merging it due to some reason, then v1.2.0-beta.0.osoe-482 would show up as more recent. This would have the unwanted effect of pointing people to use that instead of the released version, and would make it more of a hassle to update our own projects, starting with OSOCE, too. See the resolved comments in the wiki on the conversations about this.
  2. Yes, same reason as for OSOE-150: Add PowerShell static code analysis #1.
  3. Unlike dev, anything on an issue branch can change in any way, and nobody should rely on this not being the case (otherwise we'd constrain ourselves in what happens for a WIP feature in an issue branch). Thus, for the lack of anything more appropriate, alpha is a better indicator of what you should expect (or rather, why you shouldn't use it apart from the very constrained case of working on the given issue).
  4. Here they are: https://github.com/Lombiq/PowerShell-Analyzers/releases. To be clear, our issue-specific alphas shouldn't have such GitHub releases, specifically because they aren't to be consumed by the general public and thus shouldn't be advertised as generally available.
  5. Marking them with a version that communicates "you shouldn't have any expectations for this, it's not production-ready, only use it if you know what you're doing".

Please sign in to comment.