search

Brightspace / D2L.Security.OAuth2

Brightspace OAuth 2.0 for C#
Apache License 2.0
7 stars 16 forks source link

Consider a uniform version number for this suite of packages #31

Closed j3parker closed 8 years ago

j3parker commented 8 years ago

This repo contains these NuGet packages:

D2L.Security.OAuth2
D2L.Security.OAuth2.WebApi
D2L.Security.OAuth2.TestFramework

They are currently versioned independently.

I think it'd make sense for them to be versioned in lock-step because these libraries are highly coupled (by design - the second ones are extensions) so it is confusing to keep track of compatibility versions of each currently.

It would also have some nice advantages for development: you can put all csproj into the same sln and use solution references instead of bringing them in as NuGet packages (what D2L.Security.OAuth2.WebApi has always had to do with D2L.Security.OAuth2.) Right now the feedback loop from change in core -> changes in WebApi is really annoying.

I think this would be a good general approach for the "core library + extensions" pattern.

Thoughts? @omsmith @brian-pearson @mpharoah-d2l

P.S.

The WebApi repo was merged into this one to make dev easier.

It matches the style of what MS is doing with .NET Core stuff (e.g. EntityFramework is many packages but one repo.)

AppVeyor CI also handles multiple-package case just swell.

j3parker commented 8 years ago

It might also be what MS is doing, I'll investigate

j3parker commented 8 years ago

On further thought, probably only necessary/useful for major versions?

j3parker commented 8 years ago

The form this might have to take, I imagine, is to create a directory for local nupkg and have VS build and pack them into there. Need to investigate if this approach is compatible with .NET core non-VS builds.

mpharoah-d2l commented 8 years ago

How does the packaging work in this case? Are all 3 assemblies put into the same NuGet package? Or is it still 3 separate NuGet packages, but we just use solution references in the project instead of referencing the assemblies in the packages folder?

j3parker commented 8 years ago

3 separate packages (to segregate dependencies)

Would be happy with solution folder. Would also be happy if we could build directly into packages (gross?) or to a local Nuget feed (which would get pulled into packages ultimately)

Basically if I could edit the core and webapi libs at the same time without publicly publishing the core changes first I'd be a happy camper.

omsmith commented 8 years ago

Does a breaking change to TestFramework necessitate a major bump across the board?

j3parker commented 8 years ago

I think it would, yeah

brian-pearson commented 8 years ago

+1 to this idea/approach. As I've recently experienced, having separate version numbers make things more complicated/confusing when consuming ...

As owen says publishing in lock step maybe has the slight disadvantage like forcing a major bump for changes to the TestFramework which is maybe lame, but oh well, it's worth it for the clarity.

omsmith commented 8 years ago

I'd like to do this today.

Bump them all as 5.0.1 (could put it to 5.0.0, but suggesting .1 for the git tag's sake)