Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose the prelease part of SemVerPadded #651

Closed
sunsided opened this issue Sep 21, 2015 · 7 comments
Closed

Expose the prelease part of SemVerPadded #651

sunsided opened this issue Sep 21, 2015 · 7 comments

Comments

@sunsided
Copy link

For dnx/dnu-based builds (#647), I'm required to set the DNX_BUILD_VERSION environment, which will replace the placeholder asterisk in project.json. An DNX_BUILD_VERSION=unstable1234 with a 1.0.0-* setting would result in a 1.0.0-unstable1234 build and NuGet package.

In order to circle around incompatibilites with dnx-based, GitVersion and v2-based NuGet feeds, the prerelease and padded prerelease part (e.g. unstableXXXX of LegacySemVerPadded) is required as a separate export.

Alternatively a GitVersion.DnxBuildVersion could be exposed.

@sunsided sunsided changed the title Expose the prelease part of semverpadded Expose the prelease part of SemVerPadded Sep 21, 2015
@sunsided
Copy link
Author

For the record, I worked around this at the moment using a powershell script in TeamCity to split the version number and then pad it manually. The script can be found in this gist.

@JakeGinnivan
Copy link
Contributor

I am struggling to find where DNX_BUILD_VERSION and such is documented. Does it automatically remove the - for you if no build version is specified?

@asbjornu
Copy link
Member

asbjornu commented Oct 5, 2015

Woudn't GitVersion.DnxBuildVersion be the cleanest and most consistent way to expose this?

@sunsided
Copy link
Author

sunsided commented Oct 5, 2015

@JakeGinnivan there's probably no point searching for any documentation at the moment, it's still in the process of being written for very large parts. But yes, indeed, it's as you suspect. Have a look at my comments on #647.
@asbjornu I personally dislike this option as it implies the usage. As such, it might underly some constraints the user's not aware of if he requires the same information elsewhere. If the tag part of the nuget version is all he needs, why not use that. That said, I'm fine with either option.

@JakeGinnivan
Copy link
Contributor

I am leaning towards @sunsided's idea, I wasn't a massive fan of NuGetVersion because GitVersion was supposed to be agnostic but it did make it more discoverable. For DNX I'm not so sure as it is far more lightweight and hopefully doesn't have all the issues NuGet has.

We should just expose BuildNumber which is normally commit count, and also expose BuildNumberPadded. I also think we should have PreReleaseDash or something for doing manual concatenation rather than PreReleaseTagWithDash

@asbjornu
Copy link
Member

asbjornu commented Oct 5, 2015

@JakeGinnivan Sounds good! 👍

@JakeGinnivan
Copy link
Contributor

I think this is covered by existing variables plus #742

Am I missing anything?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants