search

drewnoakes / xmp-core-dotnet

.NET library for working with the Extensible Metadata Platform (XMP)
60 stars 22 forks source link

Nuget package version not matching assembly version #29

Closed Tasteful closed 7 years ago

Tasteful commented 7 years ago

Any reason that the nuget and assembly version not is the same?

Nuget version: 2.0.1 Assembly version: 5.1.2.0

drewnoakes commented 7 years ago

The versioning situation is confusing and could be improved, but conceptually there are two versions involved.

A. The version of the specification (Adobe's XMPCore API) B. The version of the implementation

Maybe the versions could be standardised as A.A.A.B, where we bump B for bug fixes and changes unrelated to the specification.

Thoughts?

Tasteful commented 7 years ago

I prefer to use http://semver.org/ for versioning and also have the package and assembly version the same, but that only working for the implementation version.

The reason that I prefer that it is the same is when you debug and try to find and error in your solution it is easier to see that the correct dll is deployed in the bin folder than trying to find and remember the specification version.

I think it is enough to have the specification version in the description so that anyone that are searching for the nuget-package will see directly the specification version.

When using strong name signed assemblies it is the assembly version that is used when making references and that should to be updated between releases to ensure that correct assembly is used.

drewnoakes commented 7 years ago

I agree that the assembly version should change for each NuGet package version, and that they match.

SemVer is cool and I generally use it for new projects.

Going forward I think the best approach would be to have the next release be 5.1.3.0, and if patches are required without the specification updating, then we'll use 5.1.3.1.

If we go this route then I'll document as much on the README.

Tasteful commented 7 years ago

That approach is working for me.

I don't see that you need to make any release directly, think it is better to fix the same in https://github.com/drewnoakes/metadata-extractor-dotnet before making the release. I will fix solution upgrade for this also during the day and make an PR there.

drewnoakes commented 7 years ago

If you want to make MetadataExtractor support strong names too, then you'll need a release here, no?

Tasteful commented 7 years ago

Yes and no :)

I can use an own build of the nupkg during upgrade. To get appvayor to work i probably need the package public accessible but can use an temporary myget feed.