Add dev build version suffix #2254

bahusoid · 2019-10-19T06:50:41Z

Related to #2251

With current PR state prepared nuget package looks like:
NHibernate.5.3.0-dev.2645.nupkg

hazzik · 2019-10-19T08:02:00Z

I think we need to have different suffixes for PRs and master branch. The "NHibernate (Release)" build runs for all branches.

bahusoid · 2019-10-19T08:07:19Z

I think we need to have different suffixes for PRs and master branch.

I'm not sure I understand the whole plan. Why? Are we going to publish PR binaries too?

hazzik · 2019-10-19T08:10:52Z

Are we going to publish PR binaries too?

Not sure, but why not?

hazzik · 2019-10-19T08:14:09Z

Also, the publish step in TC could not be run only on specific branch.

bahusoid · 2019-10-19T08:48:09Z

Not sure, but why not?

Wouldn't it be excessive? All those temporary in progress pr binaries... I don't think publishing them is a good idea.

Also I'm currently not sure how to detect if it's PR build or not.

build-common/common.xml

default.build

maca88 · 2019-10-19T15:21:03Z

Wouldn't it be excessive? All those temporary in progress pr binaries... I don't think publishing them is a good idea.

I have the same thinking, I think that we should start only with publishing master branch for now and later if we see the need to have also PRs included, we could do that later.

fredericDelaporte · 2019-10-19T23:27:48Z

I am agree on not publishing packages for PRs, at least for now. But if possible, also include release fix branches (starting from 5.3.x).
Once we see how it fares with master and release branches "nightly builds", maybe we could reconsider whether it should also build PR, but for a start I think it is better to not build them.

bahusoid · 2019-10-20T07:25:07Z

Guys I won't be able to do any coding in the following 3 weeks. So here some thoughts on how we can proceed further if anyone wants to step in.

It seems this PR is ready - it provides uniquely versioned binaries. And I think publishing can be implemented in another PR
It seems publishing should be implemented inside nant build script but publishing parameters should be supplied from Team City. We can create parametrized version of nugetpush and use it for publishing.

For now I think of the following parameters that required on Team City (I've actuality already played with Team City parameters and added some of them to realease build)
system.nuget.publishing - Allows to disable publishing for build. I think It also would be good if publishing is disabled by default in case manual build triggering (I tried to implement this behavior in param settings but not sure if it actually works as I intended). So user should explicitly enable publishing in custom build options
system.nuget.branchNameRegex - Regex matching if publishing is required for this branch. Currently supplied value most probably wrong
system.build.branchName - Branch name. Actually not sure what exactly is supplied by Team City
... (params for publishing like publishUrl, credentials and so on)

Params are available in nant as properties without system. prefix - $(nuget.publishing)
Parameters need to be set to some default value before using - otherwise other builds will fail. Something like:

<property name="nuget.publishing" value="false" overwrite="false" />

fredericDelaporte · 2019-10-20T18:04:29Z

I do not get how we generate an actual release from this. I mean, NuGet package without the dev prefix, for actually releasing a new version.
Checking the release artifacts, I see the assembly has a 5.3-dev product version, while the NuGet is versioned 5.3.0-dev. Is this expected?

bahusoid · 2019-10-20T18:16:13Z

I do not get how we generate an actual release from this.

This pr should not affect release publishing. Just delete the suffix in release PR and do your release procedure as always. Maybe we should also add logic to skip dev publishing if suffix is missed.

I see the assembly has a 5.3-dev product version, while the NuGet is versioned 5.3.0-dev. Is this expected?

That's just default behavior. Yeah - I guess it's better to use 3 digit version for consistency.

bahusoid · 2019-10-20T18:33:48Z

And after release with the next PR or as separate commit we should add dev suffix back and specify next version number. That's the plan.

hazzik · 2019-10-21T09:31:19Z

Just delete the suffix in release PR and do your release procedure as always. Maybe we should also add logic to skip dev publishing if suffix is missed.

And after release with the next PR or as separate commit we should add dev suffix back and specify next version number. That's the plan.

Too much friction in my mind.

bahusoid · 2019-10-21T09:33:57Z

First step is currently done anyway - version is updated in release PR.
And regarding second - that's the way to keep right versioning.. Do you want to keep dev builds be published as 5.3 after release?

bahusoid · 2019-10-21T09:41:42Z

I don't see it as to much friction. As I said above I think without dev prefix - dev publishing should be disabled. So there is no rush in making those changes. PRs can be merged without it after release - they just won't be published.
And when we feel that it's time to publish and know next version we add it along with dev suffix. IMHO it's the right way to do it - published dev builds should have correct version.

default.build

fredericDelaporte · 2019-10-21T21:18:13Z

To reduce the friction, we may, in the same release package, generate both nuget with dev prefix and without.
The one with dev prefix would be pushed to MyGet, the other one not pushed anywhere excepted manually.
The binaries for the release zip should be generated without the dev prefix then.
We will still have to commit a version change after publishing a release in order to adjust the dev version. But at least we will no more need to changed the version in the last release PR release.
(I still like the current situation where we only change it in release PR, without any need to change it afterward, excepted that it causes the dev version to be currently misleading.)

Or maybe, to allow handling it from the release PR, handle a release version and a dev version in the build files, with generation of NuGet packages for both, release zip for release.
The release version will lag behind the dev version. The release PR will update both. It will cause generation and publishing of a vNext dev version along with the release, but do we care?

bahusoid · 2019-10-22T07:17:38Z

Your suggestions looks similar to this. And it adds additional full project recompilation + nuget packaging on each release build execution.

We will still have to commit a version change after publishing a release in order to adjust the dev version.

So all it saves is one edit in release PR - dev suffix removal. If you are OK with additional commit why bother at all with this additional development.

Regarding updating two versions in release PR - you still need to manually adjust version in release branch. And you must know next version beforehand - I see it as additional inconvenience.

Bumping version commit is something that could be done easily form github UI without PR. I don't see why it's considered so much trouble and worth adding additional 30+ secs on each release build execution.

bahusoid · 2020-04-22T19:17:49Z

No matter what we decide regarding publishing I think this PR is useful anyway. It minimizes frictions that are required during release - version in common.xml is no longer need to be updated manually

And let's start with something - I believe it's a minimal changes that allow us to publish dev builds.

fredericDelaporte

ReleaseProcedure.txt needs an update. Some of its instructions are no more valid with this PR. And it should contain additions to tell how to generate the release packages (zip and NuGet, without dev suffix).

There is also a version into doc\reference\master.xml, which is still 5.2 while this PR bumps the version to 5.3. This causes the reference documentation generated by build to still be labeled 5.2, while the binaries are labelled 5.3.

doc/NHibernate.shfbproj.template

bahusoid · 2020-04-26T18:50:58Z

ReleaseProcedure.txt needs an update. Some of its instructions are no more valid with this PR. And it should contain additions to tell how to generate the release packages (zip and NuGet, without dev suffix).

Ok will check it tomorrow.

There is also a version into doc\reference\master.xml, which is still 5.2 while this PR bumps the version to 5.3. This causes the reference documentation generated by build to still be labeled 5.2, while the binaries are labelled 5.3.

I don't think we should care about generated documentation as long it's not published. So I think it's OK to update it only with release - just to minimize the hassle with bumping dev version.

fredericDelaporte · 2020-04-26T18:58:06Z

I don't think we should care about generated documentation as long it's not published. So I think it's OK to update it only with release - just to minimize the hassle with bumping dev version.

Why not, provided we have proper instructions into ReleaseProcedure.txt.

bahusoid · 2020-04-27T10:08:52Z

appveyor.yml

@@ -1,4 +1,4 @@
-version: 5.2.7.{build}
+version: '{build}'


In attempt to minimize the frictions. I see no point in this - appveyour shows branch or tag if available. IMHO that's quite enough:

bahusoid · 2020-04-27T10:10:47Z

Why not, provided we have proper instructions into ReleaseProcedure.txt.

I have nothing to add except clearing VersionSuffix before release. Do you have something else in mind?

build-common/NHibernate.props

build-common/common.xml

ReleaseProcedure.txt

build-common/NHibernate.props

bahusoid changed the title ~~WIP Add dev build version prefix~~ WIP Add dev build version suffx Oct 19, 2019

bahusoid changed the title ~~WIP Add dev build version suffx~~ WIP Add dev build version suffix Oct 19, 2019

bahusoid force-pushed the version branch 2 times, most recently from d6acfe1 to af7854c Compare October 19, 2019 07:07

This comment has been minimized.

Sign in to view

hazzik reviewed Oct 19, 2019

View reviewed changes

build-common/common.xml Outdated Show resolved Hide resolved

hazzik reviewed Oct 19, 2019

View reviewed changes

default.build Outdated Show resolved Hide resolved

This comment has been minimized.

Sign in to view

bahusoid changed the title ~~WIP Add dev build version suffix~~ Add dev build version suffix Oct 20, 2019

hazzik reviewed Oct 21, 2019

View reviewed changes

default.build Show resolved Hide resolved

bahusoid added 4 commits April 22, 2020 21:57

Add dev build version suffix

03d9ab7

Commented and try to get project.version from project

af29e0e

Try to fix project.version

08f02dc

Try to handle missing build.counter

b948674

bahusoid added 2 commits April 22, 2020 22:00

Restore HelpFileVersion for API docs

504f5c1

Update VersionPrefix to 5.3.0

47e92b1

bahusoid force-pushed the version branch from 8dbef19 to 47e92b1 Compare April 22, 2020 19:03

fredericDelaporte reviewed Apr 26, 2020

View reviewed changes

doc/NHibernate.shfbproj.template Show resolved Hide resolved

bahusoid added 2 commits April 27, 2020 12:58

Remove version from appveyor. Update release procedure

055bb2e

try to fix appveyor.yml

9a60c7b

bahusoid commented Apr 27, 2020

View reviewed changes

hazzik reviewed Apr 27, 2020

View reviewed changes

build-common/NHibernate.props Outdated Show resolved Hide resolved

bahusoid added 5 commits April 28, 2020 01:53

Make assembly version as major.minor.0.0

88c1cc1

more accurate regex

3568512

Attempt to automate doc version generation

e8de8f4

attempt 2

064a3f1

Adjust ReleaseProcedure.txt

8339799

fredericDelaporte added c: Toolset p: Minor t: Improvement labels Apr 29, 2020

fredericDelaporte reviewed Apr 29, 2020

View reviewed changes

build-common/NHibernate.props Outdated Show resolved Hide resolved

build-common/NHibernate.props Show resolved Hide resolved

build-common/common.xml Show resolved Hide resolved

ReleaseProcedure.txt Show resolved Hide resolved

ReleaseProcedure.txt Outdated Show resolved Hide resolved

avoid regex; avoid dirty workspace

62b6f96

fredericDelaporte previously approved these changes May 3, 2020

View reviewed changes

ReleaseProcedure.txt Show resolved Hide resolved

build-common/NHibernate.props Outdated Show resolved Hide resolved

Add buildnumber to FileVersion for dev builds

fe0dcaf

bahusoid dismissed fredericDelaporte’s stale review via fe0dcaf May 4, 2020 06:36

fredericDelaporte approved these changes May 4, 2020

View reviewed changes

fredericDelaporte added this to the 5.3 milestone May 9, 2020

fredericDelaporte merged commit e0de3ab into nhibernate:master May 9, 2020

fredericDelaporte added the r: Fixed label May 9, 2020

bahusoid mentioned this pull request May 9, 2020

Publish development nightly builds on nuget #2251

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add dev build version suffix #2254

Add dev build version suffix #2254

bahusoid commented Oct 19, 2019 •

edited

Loading

hazzik commented Oct 19, 2019

bahusoid commented Oct 19, 2019

hazzik commented Oct 19, 2019

hazzik commented Oct 19, 2019

This comment has been minimized.

bahusoid commented Oct 19, 2019

This comment has been minimized.

maca88 commented Oct 19, 2019

fredericDelaporte commented Oct 19, 2019

bahusoid commented Oct 20, 2019

fredericDelaporte commented Oct 20, 2019

bahusoid commented Oct 20, 2019

bahusoid commented Oct 20, 2019

hazzik commented Oct 21, 2019 •

edited

Loading

bahusoid commented Oct 21, 2019 •

edited

Loading

bahusoid commented Oct 21, 2019 •

edited

Loading

fredericDelaporte commented Oct 21, 2019 •

edited

Loading

bahusoid commented Oct 22, 2019 •

edited

Loading

bahusoid commented Apr 22, 2020

fredericDelaporte left a comment

bahusoid commented Apr 26, 2020

fredericDelaporte commented Apr 26, 2020

bahusoid Apr 27, 2020

bahusoid commented Apr 27, 2020

Add dev build version suffix #2254

Add dev build version suffix #2254

Conversation

bahusoid commented Oct 19, 2019 • edited Loading

hazzik commented Oct 19, 2019

bahusoid commented Oct 19, 2019

hazzik commented Oct 19, 2019

hazzik commented Oct 19, 2019

This comment has been minimized.

bahusoid commented Oct 19, 2019

This comment has been minimized.

maca88 commented Oct 19, 2019

fredericDelaporte commented Oct 19, 2019

bahusoid commented Oct 20, 2019

fredericDelaporte commented Oct 20, 2019

bahusoid commented Oct 20, 2019

bahusoid commented Oct 20, 2019

hazzik commented Oct 21, 2019 • edited Loading

bahusoid commented Oct 21, 2019 • edited Loading

bahusoid commented Oct 21, 2019 • edited Loading

fredericDelaporte commented Oct 21, 2019 • edited Loading

bahusoid commented Oct 22, 2019 • edited Loading

bahusoid commented Apr 22, 2020

fredericDelaporte left a comment

Choose a reason for hiding this comment

bahusoid commented Apr 26, 2020

fredericDelaporte commented Apr 26, 2020

bahusoid Apr 27, 2020

Choose a reason for hiding this comment

bahusoid commented Apr 27, 2020

bahusoid commented Oct 19, 2019 •

edited

Loading

hazzik commented Oct 21, 2019 •

edited

Loading

bahusoid commented Oct 21, 2019 •

edited

Loading

bahusoid commented Oct 21, 2019 •

edited

Loading

fredericDelaporte commented Oct 21, 2019 •

edited

Loading

bahusoid commented Oct 22, 2019 •

edited

Loading