On 6/15/22 3:05 AM, Neil C Smith wrote:
On Tue, 14 Jun 2022 at 19:28, Ernie Rael <[email protected]> wrote:
I built nb based on current delivery branch for local use (I see that
release140 is now available). I'd like to know what difference there is
from this to what is released.
The delivery branch is transitory and soon to be deleted! You cannot
build the release from it - you need to use the release140 branch.
Release info is based on branch and git hash. The git hash of the
release does not even exist in the delivery branch.
I have a github fork of NB, the fork does not have release140 branch,
don't know how to get all the branches into the github fork, I pull from
the fork to build locally (guess that's a bad idea). So I pulled from
the main repo to existing local repo and that picked up release140. Diff
showed release140 == delivery, I updated locally to release140 for
sanity. Obviously my github, and git, skill are lacking...
Without it, you
get the default dev meta info.
"The git hash" is some magic I wasn't aware of: netbeans-jenkins-lib.
I'm guessing that since I use hg-git to create/update my local nb master
and create local clones from that, then this particular magic might be
out of reach no matter branch I build from.
I built from distributed netbeans-src this morning, and a cursory look
shows that it has release characteristics. Thanks. I also copied in some
source files with things I'm working on, and it still thinks it's
release 14.
Aha, the json file has update_url,plugin_url. I still don't see where
netbeans.conf comes from. Are there other changes?
Here's hoping I never have to use metabuild...=.
-ernie
On Tue, 14 Jun 2022 at 20:28, John Neffenger <[email protected]> wrote:
$ diff -qr ./ ~/opt/netbeans-14-rc6-src/
...
It makes me nervous that we're shipping a release of NetBeans that is
built from source code with no relation to a branch or release tag on
GitHub. We're losing the cryptographic guarantee on the source code
provided by the Git commit hashes.
Tags are purely a convenience, after the fact (as just written in
another thread). The release is linked to branch and git hash via -
https://github.com/apache/netbeans-jenkins-lib/blob/master/meta/netbeansrelease.json#L732
The primary difference between the source bundle and a git checkout is
the lack of .git. So, the source bundle pre-caches the git hash (also
used for module impl versions) and metadata info necessary for the
build, and we then sign that bundle so it cannot be altered or changes
to netbeansrelease.json break builds.
A few files are filtered out and/or altered. There are some reasons -
more so during the initial ASF transition.
I can think of at least one person who checks the diff between source
bundle and git repository when voting - that could be made more
explicit in the voting instructions perhaps?
Having metadata in a separate repository has its pros and cons, but it
replaces a bunch of complications in managing our current release
process.
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
