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+Release+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/asfMainNetBeansBuild.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
