Create account / Log in

Moving on with deployment and build handling

Discussion area for the development team.

Moderators: uckelman, Tim M

Re: Moving on with deployment and build handling

Postby Cattlesquat » July 22nd, 2020, 2:35 am

Okay, "master" might be back to normal at least.
User avatar
Cattlesquat
 
Posts: 953
Joined: December 2nd, 2019, 4:57 pm
Location: Baltimore, Maryland, USA

Re: Moving on with deployment and build handling

Postby Cattlesquat » July 22nd, 2020, 2:50 am

Flint1b wrote:Good question..

Rename the local branch HTMLChatter to something else like HTMLChatter-old, then create a new branch with the exact name "HTMLChatter" off current master, then merge my branch into that one, then force push.. This should replace the whole PR with that one single commit.

Just make sure it works and is what you intended to change before you push, I didn't even try to compile it, there were some deletions in the merge conflicts and if I understood correctly you deleted an inner class "UI".


Unfortunately that will probably require giving me a very precise set of git commands to do some of those things (renaming branch, creating one off master... local master?, not sure what "merge your branch into that one" means, and how to do a force push right).

I'm beginning to thing better options might include:
* Just leaving the PR the way it is?
* Is there a way to just take the PR that's up there and squash it into a single commit?
* Should I just get the latest version of the one-or-two-files that actually changed, "copy it into a directory", and then copy it on top of some new branch & new PR I make, and forget the whole disastrous-series-of-everything ever happened?

Of course I can only imagine spending the next week trying to fix all the OTHER PR's.

You may already have gone to bed by now and that's fine.

Brian

p.s. I've confirmed that there are only two files that ever "actually" changed in this whole PR -- Chatter.java and VASSAL.properties. It seems like easiest might be to just copy them out and make a brand new PR as if I'd just "written them from scratch"?
User avatar
Cattlesquat
 
Posts: 953
Joined: December 2nd, 2019, 4:57 pm
Location: Baltimore, Maryland, USA

Re: Moving on with deployment and build handling

Postby Cattlesquat » July 22nd, 2020, 3:15 am

I stuck up a completely fresh PR of the Chatter, just copying the "final versions" of the only two files that changed into a new fresh branch and checking it in. That took about 15 minutes instead of several hours plus it's not taking everybody else's time. So unless there's some major downside in that, I might spend tomorrow just fixing my PR's "the old fashioned way, by copying shit between directories", because I bet that takes less of my time and nearly none of yours & Joels.

The only one I'm really worried about is the "Editor" one because of the refactor you did - I'm not sure I can pull that off.

You guys can post thoughts when you get back on tomorrow.

Brian
User avatar
Cattlesquat
 
Posts: 953
Joined: December 2nd, 2019, 4:57 pm
Location: Baltimore, Maryland, USA

Re: Moving on with deployment and build handling

Postby Flint1b » July 22nd, 2020, 10:51 am

That works too, sometimes I forget that this old-fashioned way still exists :D

The Editor PR with my refactoring, if you just copy the final version of the ConfigureTree into a new branch, it will contain all changes including the refactoring.

We could also do it like this, I make branches of your PRs, fix them so they're only 1 commit on top of master, this will take about 5-10 minutes per PR. Then you make branches from them into your repository, and push them as new PRs, this will probably take another 5-10 minutes per PR. In total it will take roughly just as much time as the old-fashioned way.
User avatar
Flint1b
 
Posts: 461
Joined: May 19th, 2020, 12:27 am
Location: Colonia Agrippina

Re: Moving on with deployment and build handling

Postby Cattlesquat » July 22nd, 2020, 1:42 pm

Okay, I'll see how far I can get on my own (I actually think we did the hardest PR first since it was the oldest and had been "rebased the wrong way" several times in its history). I may be able to get some of them to work "the right way" and the rest I'll use brute force.

Rested and ready to pull on my Merge Boots!
User avatar
Cattlesquat
 
Posts: 953
Joined: December 2nd, 2019, 4:57 pm
Location: Baltimore, Maryland, USA

Re: Moving on with deployment and build handling

Postby Flint1b » July 22nd, 2020, 4:18 pm

About the future build process with the Vassal.jar in our own maven repository:

The build process will look roughly like this:

0. prepare the release locally, finish all necessary modifications
1. set the maven version to a release number, manually or even easier with maven versions plugin: "mvn versions:set -DnewVersion=3.3.3" or "mvn versions:set -DnewVersion=3.3.3-beta1"
2. "release" the jar (add it to releases directory): "mvn clean deploy", this will add the vassal.jar, vassal-sources.jar and vassal-javadoc.jar to git's releases directory
3. add release tag "git tag 3.3.3"
4. commit and push, after this step the modules will be able to pull the new version from github via maven
5. build the linux/mac/windows/other distributions with make, distribute them however we want
6. increase maven version number for next development iteration "mvn versions:set -DnewVersion=3.3.4-SNAPSHOT"
7. commit and push

Steps 1, 2 and 3 can be probably included into the Makefile.

I will prepare a PR that shows this process in practice.
User avatar
Flint1b
 
Posts: 461
Joined: May 19th, 2020, 12:27 am
Location: Colonia Agrippina

Re: Moving on with deployment and build handling

Postby Flint1b » July 22nd, 2020, 4:35 pm

.. not sure how this would work with the current release branch, ideally the release commit would end up in the master branch, somehow, I guess we could release on another branch but then would have to merge that into master.

Or we switch to a more standard way of handling branches like git-flow.
User avatar
Flint1b
 
Posts: 461
Joined: May 19th, 2020, 12:27 am
Location: Colonia Agrippina

Re: Moving on with deployment and build handling

Postby Flint1b » July 22nd, 2020, 5:25 pm

@Joel, Vassal's "human build server", please have a look at https://github.com/vassalengine/vassal/pull/114 and let me know what you think
User avatar
Flint1b
 
Posts: 461
Joined: May 19th, 2020, 12:27 am
Location: Colonia Agrippina

Re: Moving on with deployment and build handling

Postby uckelman » July 22nd, 2020, 9:35 pm

Thus spake Flint1b:
>
> @Joel - better keep an eye on the new naming of the vassal jar, it now
> has it's version number attached, I did all I could to prevent any
> errors due to that but I haven't built actual release packages.

Something's wrong with that in master HEAD at present. I'm looking at
it now.

--
J.
User avatar
uckelman
Site Admin
 
Posts: 9014
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

Re: Moving on with deployment and build handling

Postby uckelman » July 22nd, 2020, 9:44 pm

Thus spake Cattlesquat:
> Just to make sure I know the right way, what's the best way to "create a
> new backup branch off it"?
> git checkout [branch]
> git checkout -b "some other branch name"?

These two do different things:

* git checkout foo

This checks out the branch named foo. If there's no branch named foo,
you'll get an error message.

* git checkout -b foo

This creates a branch named foo starting at the commit where you are
currently, and then checks it out.

It's equivalent to:

git branch foo
git checkout foo

when foo doesn't exist yet.

Both commands leave you on branch foo (if they succeed), but only the
second one _creates_ a branch.

--
J.
User avatar
uckelman
Site Admin
 
Posts: 9014
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

Re: Moving on with deployment and build handling

Postby Flint1b » July 22nd, 2020, 9:57 pm

Whoops... I forgot to change this, Makefile, line 52, still says 3.3.2-SNAPSHOT:

Code: Select all
JARNAME:=vassal-app-3.3.2-SNAPSHOT


... we need a process where there is only one single point of truth for the version number. Probably easiest to let the makefile set the maven number by calling "mvn versions:set" and passing the version number into that.

Here is btw a good explanation of how Maven understands version numbers: https://octopus.com/blog/maven-versioning-explained

We can still do beta releases and Maven will understand their order, but these intermediate releases "here dude with problem X try this custom release I just built" probably need to be snapshot releases with no further identification as far as Maven is concerned, just "3.3.3-snapshot from two days ago" or "that new 3.3.3-snapshot from today". We can still use the git-id-plugin though to put the git commit hash into the property file so it appears in the about dialog.
User avatar
Flint1b
 
Posts: 461
Joined: May 19th, 2020, 12:27 am
Location: Colonia Agrippina

Re: Moving on with deployment and build handling

Postby uckelman » July 22nd, 2020, 10:09 pm

Thus spake Flint1b:
>
> ... we need a process where there is only one single point of truth for
> the version number. Probably easiest to let the makefile set the maven
> number by calling "mvn versions:set" and passing the version number into
> that.
>
> Here is btw a good explanation of how Maven understands version numbers:
> https://octopus.com/blog/maven-versioning-explained[1]

The issue we're running into is that we've created two separate versioning
systems, yes.

> We can still do beta releases and Maven will understand their order, but
> these intermediate releases "here dude with problem X try this custom
> release I just built" probably need to be snapshot releases with no
> further identification as far as Maven is concerned, just
> "3.3.3-snapshot from two days ago" or "that new 3.3.3-snapshot from
> today". We can still use the git-id-plugin though to put the git commit
> hash into the property file so it appears in the about dialog.

That would be fine, but then we also need to make sure that what we
produce either is already parsed properly by the version parser or
that the version parser gets modified so it does.

I haven't been particularly satisfied with the way 'git describe' produces
version strings. It has builds between x.y.z and x.y.(z+1) as post-x.y.z
builds instad of pre-x.y.(z+1) builds. Our practice had always been the
latter before moving to git, and I think it makes more sense than what
'git describe' does.

--
J.
User avatar
uckelman
Site Admin
 
Posts: 9014
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

Re: Moving on with deployment and build handling

Postby Flint1b » July 22nd, 2020, 10:29 pm

uckelman wrote:That would be fine, but then we also need to make sure that what we
produce either is already parsed properly by the version parser or
that the version parser gets modified so it does.


If we use Maven-friendly version numbers, using the keywords that Maven understands "alpha" "beta" "snapshot", we could change our version parser to just delegate to Maven's version parser, that article I linked explains how Maven's insides work and even shows a unit test which looks a lot like our VassalVersionParser unit test.

uckelman wrote:I haven't been particularly satisfied with the way 'git describe' produces
version strings. It has builds between x.y.z and x.y.(z+1) as post-x.y.z
builds instad of pre-x.y.(z+1) builds. Our practice had always been the
latter before moving to git, and I think it makes more sense than what
'git describe' does.

I think it's not too much work setting the version number manually for releases, you do maybe 3-5 releases per month including final and beta ones, and if we create a system where there's a single point of truth for the version number, it's going to be just two small steps in the 5-15 or so total steps of the full release cycle (set the release version, after release set next maven snapshot version).

I have worked on automating builds in enterprise systems and these two steps for setting the version number were often among the last remaining steps that needed to be done manually.
User avatar
Flint1b
 
Posts: 461
Joined: May 19th, 2020, 12:27 am
Location: Colonia Agrippina

Re: Moving on with deployment and build handling

Postby uckelman » July 22nd, 2020, 10:45 pm

Thus spake Flint1b:
>
> If we use Maven-friendly version numbers, using the keywords that Maven
> understands "alpha" "beta" "snapshot", we could change our version
> parser to just delegate to Maven's version parser, that article I linked
> explains how Maven's insides work and even shows a unit test which looks
> a lot like our VassalVersionParser unit test.

We don't require a total ordering among version numbers. Our acutal
requirements are the following:

* The dotted decimal parts are ordered in the conventional way
* x-tag < x

There are a lot of partial orderings comaptible with that. (Nothing
even relies on x.y.z-beta1 sorting before x.y.z-beta2, so long as they
both sort before x.y.z.)

We never need to compare arbitrary pairs of versions, either---one of
the versions being compared is always the version running---so that
means we no longer need to care how anything old sorts beyond the
dotted decimal portion.

We're fairly unconstrained in this area, so it looks like
ComparableVersion would work.

Give it a try?

> I think it's not too much work setting the version number manually for
> releases, you do maybe 3-5 releases per month including final and beta
> ones, and if we create a system where there's a single point of truth
> for the version number, it's going to be just two small steps in the
> 5-15 or so total steps of the full release cycle (set the release
> version, after release set next maven snapshot version).

I don't mind setting the version number; in fact, it's one of those
things I would not want to happen automatically. My complaint was
more that 'git describe' doesn't work very well because it's based
on distance from a tag in the past, when it's more perspicuous to
indicate that you're heading toward the next release with the version
number. (git describe obviously _can't_ do this, because you'd be asking
it to count towards a tag which doesn't exist yet...)

--
J.
User avatar
uckelman
Site Admin
 
Posts: 9014
Joined: December 10th, 2007, 9:48 am
Location: Durham, England

Re: Moving on with deployment and build handling

Postby Flint1b » July 22nd, 2020, 11:44 pm

uckelman wrote: * x-tag < x


Little problem here with ComparableVersion :D

For well-known identifiers like "alpha" "beta" "rc",
* 2.0.1-alpha1 < 2.0.1
* 2.0.1-beta2 < 2.0.1
* 2.0.1-rc7 < 2.0.1

But for other, arbitary strings it is the other way round:
* 2.0.1-xyz > 2.0.1
* 2.0.1-xyz-80 > 2.0.1

Why do we need to order these like that, shouldn't the alpha/beta/rc identifiers be enough?
User avatar
Flint1b
 
Posts: 461
Joined: May 19th, 2020, 12:27 am
Location: Colonia Agrippina

PreviousNext

Return to Developers

Who is online

Users browsing this forum: No registered users and 2 guests

cron