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

Generate file version, remove Common.props #813

Merged
merged 1 commit into from Dec 11, 2020

Conversation

lahma
Copy link
Collaborator

@lahma lahma commented Dec 9, 2020

Now NuGet package version still the same as before (containing beta), file version is 3.0.0.BuildVersion, assembly version is 3.0.0.0 (no binding redirects).

using System.Diagnostics;
using System.Reflection;
using System.Resources;
using System.Runtime.CompilerServices;
using System.Runtime.Versioning;

// Assembly Jint, Version=3.0.0.0, Culture=neutral, PublicKeyToken=2e92ba9c8d81157f
// MVID: C05F92A7-20A6-44C7-9F76-28315D4690DB
// Assembly references:
// netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51
// Esprima, Version=2.0.0.0, Culture=neutral, PublicKeyToken=2e92ba9c8d81157f

[assembly: Extension]
[assembly: CompilationRelaxations(8)]
[assembly: RuntimeCompatibility(WrapNonExceptionThrows = true)]
[assembly: Debuggable(DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints)]
[assembly: InternalsVisibleTo("Jint.Tests, PublicKey=0024000004800000940000000602000000240000525341310004000001000100bf2553c9f214cb21f1f64ed62cadad8fe4f2fa11322a5dfa1d650743145c6085aba05b145b29867af656e0bb9bfd32f5d0deb1668263a38233e7e8e5bad1a3c6edd3f2ec6c512668b4aa797283101444628650949641b4f7cb16707efba542bb754afe87ce956f3a5d43f450d14364eb9571cbf213d1061852fb9dd47a6c05c4")]
[assembly: InternalsVisibleTo("Jint.Benchmark, PublicKey=0024000004800000940000000602000000240000525341310004000001000100bf2553c9f214cb21f1f64ed62cadad8fe4f2fa11322a5dfa1d650743145c6085aba05b145b29867af656e0bb9bfd32f5d0deb1668263a38233e7e8e5bad1a3c6edd3f2ec6c512668b4aa797283101444628650949641b4f7cb16707efba542bb754afe87ce956f3a5d43f450d14364eb9571cbf213d1061852fb9dd47a6c05c4")]
[assembly: TargetFramework(".NETStandard,Version=v2.0", FrameworkDisplayName = "")]
[assembly: AssemblyCompany("Sebastien Ros")]
[assembly: AssemblyConfiguration("Release")]
[assembly: AssemblyCopyright("Sebastien Ros")]
[assembly: AssemblyDescription("Javascript interpreter for .NET.")]
[assembly: AssemblyFileVersion("3.0.0.1947")]
[assembly: AssemblyInformationalVersion("3.0.0-beta-1947+320f831b74155dff020149ab531183f4631c8731")]
[assembly: AssemblyProduct("Jint")]
[assembly: AssemblyTitle("Jint")]
[assembly: AssemblyMetadata("RepositoryUrl", "https://github.com/sebastienros/jint.git")]
[assembly: NeutralResourcesLanguage("en-US")]
[assembly: AssemblyVersion("3.0.0.0")]

fixes #492

@lahma lahma marked this pull request as draft December 9, 2020 06:23
@sebastienros
Copy link
Owner

After that we just need to remove the beta from the suffix to make it a stable release?

@lahma
Copy link
Collaborator Author

lahma commented Dec 9, 2020

That's the technical version. Are we sure that the public API as great as it can get? I'd make sure that there's nothing eerily possibly to hurt us by needing to support. EnterExecutionContext etc. Then here's Execute(...).GetCompletionValue() vs Evaluate(). All kinds of things still public that might be internal until some cries about them.

@sebastienros
Copy link
Owner

What I meant was purely technical, not assuming taht we go stable once the Pr is merged. Just to know what the actions are to effectively have a stable version number.

@lahma
Copy link
Collaborator Author

lahma commented Dec 11, 2020

Yes the version number 3.0.0.0 is just for binding. When we git RTM NuGet package is 3.0.0 with file version of say.. 3.0.0.345, assembly version 3.0.0. Next should be NuGet: 3.0.1, FileVersion: 3.0.1.456, Assembly: 3.0.1.0 . Or that just my thinking.

  • NuGet: marketing
  • Assembly: logical version for bindings
  • FileVersion (like InformationVersion): technical details to find the actual thing in VCS

@sebastienros
Copy link
Owner

So a stable release means always setting the version manually with the commit, right?

@lahma
Copy link
Collaborator Author

lahma commented Dec 11, 2020

Yes, until there's some GitVersion or similar to help / sniffing the tag, like if tag matches "vX.Y.Z" and we are in master, extract numerical value and use it.

@sebastienros
Copy link
Owner

Can GitHub actions have parameters, like with a custom form? that would ask for the version number, and we wouldn't have to commit it in code.

@sebastienros
Copy link
Owner

Actually a custom tag syntax might be the best. So if a tag is added to the release/3.x branch, we can then ensure it starts with 3.x.y.z and publish the package.

@lahma
Copy link
Collaborator Author

lahma commented Dec 11, 2020

I do something similar in Quartz. So if no tag suffix is preview and otherwise trust in code. Would probably be better to just pass the tag as Version like you suggested.

Can we merge this in interim?

@sebastienros
Copy link
Owner

merge

@lahma lahma marked this pull request as ready for review December 11, 2020 15:30
@lahma lahma merged commit d399250 into sebastienros:dev Dec 11, 2020
@lahma lahma deleted the add-version-info branch December 11, 2020 15:30
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

Successfully merging this pull request may close these issues.

Version is 0.0.0.0
2 participants