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

1.0.0 release #16

Closed
46 tasks done
adamralph opened this issue Oct 21, 2018 · 18 comments
Closed
46 tasks done

1.0.0 release #16

adamralph opened this issue Oct 21, 2018 · 18 comments
Milestone

Comments

@adamralph
Copy link
Owner

adamralph commented Oct 21, 2018

@adamralph adamralph added this to the 1.0.0 milestone Oct 21, 2018
@adamralph adamralph assigned adamralph and unassigned adamralph Oct 21, 2018
@adamralph
Copy link
Owner Author

@bording I think this could be ready for beta now. What do you think?

One thing I'm still wondering about is whether the message about which commit is being used should always be printed to stderr. This can bloat the output significantly when a solution has multiple projects, e.g. during build:

MinVer: Using { Sha: fd13225, Tag: '2.4.0', Version: 2.4.0, Height: 45 }
2.4.1-alpha.0.45
Xbehave.Core -> C:\code\adamralph\xbehave.net\src\Xbehave.Core\bin\Release\netstandard1.1\Xbehave.Core.dll
MinVer: Using { Sha: fd13225, Tag: '2.4.0', Version: 2.4.0, Height: 45 }
2.4.1-alpha.0.45
MinVer: Using { Sha: fd13225, Tag: '2.4.0', Version: 2.4.0, Height: 45 }
2.4.1-alpha.0.45
Xbehave.Execution -> C:\code\adamralph\xbehave.net\src\Xbehave.Execution\bin\Release\netstandard1.1\Xbehave.Execution.dotnet.dll
Xbehave.Execution -> C:\code\adamralph\xbehave.net\src\Xbehave.Execution\bin\Release\net452\Xbehave.Execution.desktop.dll

And in the case of xbehave, again during pack:

Bullseye/pack/Xbehave.Core.nuspec: Starting...
dotnet pack src/Xbehave.Core --configuration Release --no-build
Microsoft (R) Build Engine version 15.8.169+g1ccb72aefa for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  MinVer: Using { Sha: fd13225, Tag: '2.4.0', Version: 2.4.0, Height: 45 }
  2.4.1-alpha.0.45
  Successfully created package 'C:\code\adamralph\xbehave.net\src\Xbehave.Core\bin\Release\Xbehave.Core.2.4.1-alpha.0.45.nupkg'.
Bullseye/pack/Xbehave.Core.nuspec: Succeeded. (1.3 s)
Bullseye/pack/Xbehave.nuspec: Starting...
dotnet pack src/Xbehave.Core --configuration Release --no-build
Microsoft (R) Build Engine version 15.8.169+g1ccb72aefa for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  MinVer: Using { Sha: fd13225, Tag: '2.4.0', Version: 2.4.0, Height: 45 }
  2.4.1-alpha.0.45
  Successfully created package 'C:\code\adamralph\xbehave.net\src\Xbehave.Core\bin\Release\Xbehave.2.4.1-alpha.0.45.nupkg'.
Bullseye/pack/Xbehave.nuspec: Succeeded. (1.2 s)

On one hand, I guess it could be interesting when you first start using MinVer, since the results might not be what you initially expect. Using this info, you can go and look at the git log and satisfy yourself it's doing the right thing. On the other hand, once you're comfortable that MinVer is doing the right thing, these messages could get annoying, bloating the output for little value. Options that spring to mind:

  1. Only print this message when MinVerVerbose is set to true.
  2. Support a MINVER_QUIET/MinVerQuiet property (which would probably have to take precedence over MinVerVerbose) but that's also a bit annoying to have to add whenever you install MinVer in a new project, and you're already confident that it does the right thing after using it in other projects.
  3. Attempt to print this message only once per build. I'm not sure if this is possible?
  4. Leave it as-is. 🤷‍♂️

The fact that the version number itself is printed is also a bit annoying. I guess the only way around that is to replace Exec with a custom MSBuild task which suppresses stdout, but I'm not sure I want to open that can of worms. However, since that task would not need a reference to lib2gitsharp (it would be just a generic process running task) perhaps that's not entirely unpalatable?

@bording
Copy link
Collaborator

bording commented Nov 1, 2018

@bording I think this could be ready for beta now. What do you think?

Only feature I can think of is some way to control major/minor when you want to use something other than what is being calculated, but we've already been discussing that.

One thing I'm still wondering about is whether the message about which commit is being used should always be printed to stderr.

I think option 1 sounds reasonable, only print that if MinVerVerbose is true. Or just leave it alone (option 4) and see if it bothers anyone.

Option 2 doesn't seem worth it, and I'm also not sure how you'd implement option 3, or if you'd even want to.

. I guess the only way around that is to replace Exec with a custom MSBuild task which suppresses stdout, but I'm not sure I want to open that can of worms.

If you're going to get into writing a custom MSBuild task, it doesn't really seem worth it to just suppress some output.

I still think it might be worth investigating actually invoking the MinVer logic from a task, but at this point I think it makes sense to wait on a new LibGit2Sharp release that will simplify all the native loading logic involved in getting that working.

@adamralph
Copy link
Owner Author

I think I'll go with option 4 for now and leave it alone. Other tools like Fody and GitVersion are way more verbose, but they have the advantage of using tasks, so they can hook into the MSBuild engine to do their logging, which means their logging level is controlled by the MSBuild verbosity level, either via the command line or VS settings. If I had that luxury I'd probably put this message into normal, and the rest into detailed.

I was hoping there was an MSBuild property which could tell me the logging level, but alas, there is none. I found a horrible kludge which looked promising, but unfortunately it doesn't work in VS.

I also found an old thread in the MS forums, and the proposed solution from the MS engineer was to define a custom property, and that's exactly what the OP did, with PostSharpVerbose, exactly like we have now with MinVerVerbose. 🤷‍♂️

I still think it might be worth investigating actually invoking the MinVer logic from a task, but at this point I think it makes sense to wait on a new LibGit2Sharp release that will simplify all the native loading logic involved in getting that working.

That sounds good to me.

So I guess the only outstanding thing now before beta is #63.

@adamralph
Copy link
Owner Author

Now that #63 is closed and released in alpha 10, I guess the package could be ready for beta. I'll probably upgrade all my other community projects over the weekend, and also adopt MinVerMinimumMajorMinor instead of the "dummy" tag. If all goes smoothly, beta 1 can be released next week. At that point, I'll see if some other projects feel like taking the plunge and switching to MinVer while in beta, such https:/SQLStreamStore/SQLStreamStore and https:/FakeItEasy/FakeItEasy.

@adamralph
Copy link
Owner Author

adamralph commented Nov 3, 2018

I've released alpha 11. Hopefully that's the last alpha release.

@adamralph
Copy link
Owner Author

I found another problem: #71 😭

But easy to fix. 🎉

@adamralph
Copy link
Owner Author

Released alpha 12.

@adamralph
Copy link
Owner Author

Latest version is alpha 18.

@adamralph
Copy link
Owner Author

I've just released alpha 19.

I can't think of anything else which needs doing before beta. I'll re-test all the projects listed above with alpha 19 ASAP. If everything goes smoothly, it's a beta time!

@adamralph
Copy link
Owner Author

There will be another alpha: #135 🐛

And I've just remembered some other minor things that I wanted to do before beta. 😏

@adamralph
Copy link
Owner Author

Released alpha 20. 🤞

@adamralph
Copy link
Owner Author

Released alpha 21 with #141. 🏓

@adamralph
Copy link
Owner Author

I believe the alpha testing is complete. I'll release the first beta tomorrow. :shipit:

@adamralph
Copy link
Owner Author

I'll release beta 2 shortly.

@adamralph
Copy link
Owner Author

adamralph commented Feb 10, 2019

Current status: beta 4 is out, and I'd like to upgrade a few more consumers to that version before releasing the first RC.

@adamralph
Copy link
Owner Author

Current status: RC 1 is out. Consumers are being upgraded.

@adamralph
Copy link
Owner Author

All RC 1 PR's raised.

@adamralph
Copy link
Owner Author

https://twitter.com/adamralph/status/1104333670415060992 🎉 :shipit:

@adamralph adamralph removed their assignment Jul 21, 2024
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

2 participants