Description
We need to update this for release so that when send out VF's, the proper nuget version is used. Note that 2.4.8.0 should always be reserved for the final GA release. I am not sure if this is possible, but would be awesome - even if requires manually updating appveyor.yml after every tag push.
Attachments
Issue Links
- duplicates
-
NCBC-1323 Update Core projects to Visual Studio 2017 XML based projects
-
- Resolved
-
Activity
Sorry, I was conflating appveyor and MyGet. That is actually what I am asking exactly, can we update the appveyor.yml after every release? Preferably as a trigger from the tag event? I am not sure this is possible, but if it is...we should do it!
I'm not sure we could / should automate this because we can't always be certain what the next release will be. For example: is the next next release 2.4.9 or 2.5.0 or 3.0.0. I think if we add updating the appveyor.yml to the scheduled next build number to our release process it should be fine.
| Field | Original Value | New Value |
|---|---|---|
| Status | New [ 10003 ] | Open [ 1 ] |
| Fix Version/s | 2.4.8 [ 14541 ] | |
| Fix Version/s | 2.5.0 [ 14510 ] | |
| Resolution | Fixed [ 1 ] | |
| Status | Open [ 1 ] | Resolved [ 5 ] |
That's what we have now, the version tag in appveyor.yml uses the format 2.4.8.{build} where AppVeyor appends it's own internal build number, eg the current build is 2.4.8.170. However, on tag builds we override the version to whatever the tag is, eg 2.4.8.
To ensure unofficial nuget packages that go to MyGet represent the current version, we would need to update the appveyor.yml after each release. For example, the next likely release after 2.4.8 is 2.5.0 so would set the appveyor version to 2.5.0.{build}.