Thank you all for reviewing my 12.2 u2 release attempt. Clearly my poor understanding of the purpose and behavior of release properties is the root cause why 12.2.1 version started to misbehave and why 12.2.2 bits don't have proper release properties either.
On the other hand, the hotfix still works. 12.2.2 as well as delivery branch are removing the update centers: https://github.com/apache/netbeans/pull/2757 - e.g. the hotfix really works. There are two alternative directions ahead: 1) finish the vote in progress - it's not going to be N:0 vote, but chances are it passes - the release info in binary isn't correct + yet the hotfix works + it is going to be short lived release + replaced with 13.0.0 soon + the marketplace versions will only increase 2) rebuild the binaries and call for a new vote + this time I will not mess up building the binary, hopefully - the binary is going to be different - delay: vote for 13.0 may finish meanwhile! + Martin found 12.0.0 isn't broken and works, but - downgrading/replacing marketplace bits isn't ideal It is not an easy choice (given that now we know the problems are caused by my poor understanding and the hotfix bits aren't 100% correct either), but I'd prefer to go with 1st option (e.g. let the vote go on) and hope 13.0 is out soon and fixes everything properly. -jt PS: As a homework I am going to spend an hour gaining some insight into release properties and the associated release process actions. Dne neděle 14. února 2021 19:57:42 CET, Neil C Smith napsal(a): > On Sun, 14 Feb 2021 at 14:32, Jaroslav Tulach <[email protected]> wrote: > > It is my desire to make sure 12.2.2 release is kosher as soon as possible. > > As I wrote in other reply, I am convinced that I haven't done anything > > wrong by starting the vote. > > Yes, agreed, don't think there was much choice by that point. > Although the -1 was based on the artefacts, not the retrospective > vote. > > > Is this something one should fix when preparing a release? I haven't done > > that in 12.2.1 neither when preparing current 12.2.2 - is there a > > checklist to follow to avoid this error next time? Btw. good to hear it > > is not seen as a showstopper. > > Yes, one thing Geertjan has been looking at is ensuring that the > existing documentation is more up-to-speed here, but there's the info > at > https://cwiki.apache.org/confluence/display/NETBEANS/Apache+NetBeans+Releas > e+README > > If the JSON file isn't updated with the milestone for the release / > update then the correct info is not written into the release > properties that is embedded in each source release, as well as picked > up in binary builds. > > When I say not a showstopper, I would still -1 this. But the > showstopper issue IMO is the fact that the source bundle and binary > artefact are built using *different* release properties, which means > things including UC are going to vary. > > > Are you saying the `.vsix` convenience binary selects wrong (development > > build) update center because the build process is wrong? > > Yes. If you look at the release properties file in both 12.2.1 and > 12.2.2 source zips it correctly shows the 12.2 update centre. > However, the binary build on Jenkins is picking up the wrong release > properties and writing in the daily builds update centre instead. > Check the build log for the metabuild info early in the build process > and you'll see output of what is being picked up. > > > Yup. That's what I did. I didn't realize our build is "branch sensitive"! > > That's not very common among software projects. > > Yes, it's branch sensitive, and at least the build system special > cases release*** branches. I can't remember the full reasons for this > - Eric might be able to say more, as he built most of the main Jenkins > build. There were a number of issues with just using tags IIRC. We > both looked at getting a bit more useful info from a tag checkout to > make this work, but that had issues and hasn't been followed up on as > far as I know. > > Part of the point of all this was to externalise the numerous commits > that used to be made on each release branch - version numbers, UC's, > etc. as well as give us stable across builds implementation versions > based on version and hash. > > > > It does look like the git hash is correct, > > > > Of course, it is correct! > > That was more a comment that branch info picked up in the binary build > is wrong, but it's finding the right hash. > > > Merge commit isn't needed if one stacks the new commits on top of 12.2.1 > > tag the way I did it. > > The merge commit has the benefit of giving us a hash that is > definitely only on the release branch. > > > Integrating the `.vsix` build into the main build would be great! Enough > > to > > `ant build && ant -f java/java.lsp.server/ build-vscode-ext` and record > > the > > resulting `**/*.vsix` file! > > Yes, the Groovy script here will need updating to include that - > https://github.com/apache/netbeans-jenkins-lib/blob/master/vars/asfMainNetBe > ansBuild.groovy > > That's a job for the 12.4 timeframe in my opinion - I'd rather we > didn't change the build script at this stage. For 12.3 specifying the > metabuild.branch and metabuild.hash in VSCode Jenkins build should > hopefully be enough. The other option might be to change how and on > what it's triggered so that the environment variables in the ant build > script are correct for git branch and hash - > https://github.com/apache/netbeans/blob/master/nbbuild/build.xml#L149 > > > running > > ``` > > $ git diff 12.2.1...12.2.2 | grep m2 > > That was referring to the script at > https://ci-builds.apache.org/job/Netbeans/job/netbeans-vscode/ > > Best wishes, > > Neil > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
