Dear Snapcraft,
The netbeans-dev package is actually the Apache NetBeans IDE built on Apache Infrastructure from Apache NetBeans master branch (right now the branch of the upcoming PR source).
It is created as a separate Snap package as Apache requires not to promote unreleased development code, so right now it is private, but probably can be public but not listed in the store (nice new feature BTW).
So as netbeans package, this one needs to be classic as well.
Thank you!
I was prepared to grant this request since you were granted classic access for ānetbeansā, but Iām a bit concerned by this statement: āIt is created as a separate Snap package as Apache requires not to promote unreleased development code, so right now it is private, but probably can be public but not listed in the store (nice new feature BTW).ā
Since part of classic vetting is pursuing upstream involvement, this seems counter to that. Iām going to ask the @advocacy to step in and perform the vetting.
Dear @jdstrand,
I might be not clear on the meaning āpursuing upstream involvementā.
Our plan is have an easy install-able version of our latest codebase in form of a weekly build. Snap is really ideal for that with the built-in auto update feature.
Initially we thought that using a different track like āedgeā would work. Unfortunately/fortunately Apache requires that non-released versions shall not be pushed to the public and clearly state that they are for development/testing purpose only. So I was guided to create a different package which would be private and I could invite community members to access that package.
Since then the āhidden in storeā publication level was introduced, and that actually would fulfill the Apache need and also do not require some signup from our community members we thought to give it a go for this.
So this package would be actively maintained, updated by the Apache NetBeans community, though we consider to have a much smaller user base.
Thank you for your clarifying remarks. Iām not familiar with this model for using private builds to distribute widely to opt in developers and would like others to comment.
Ping @advocacy - can you comment?
Some additional info:
Well, Iāve made the package hidden. Thatās what our intentions are. The package is not private at all, it is being built and published from the Apache infrastructure build job: https://builds.apache.org/job/netbeans-snap-weekly-master/,
The PR which is required for this build hit the master branch: https://github.com/apache/netbeans/pull/1225
So the job is tracking our main development branch, master from now.
This seems a reasonable request to me. One of the selling points of private snaps is to enable a small team of people with correct expectations to install early-access builds of software for testing / QA. Weāve certainly seen other software developers do this either with tracks or separate snaps. Theyāre mostly (AFAIAA) public though because they donāt have the somewhat onerous requirements the Apache Foundation specify.
While strange, I think this is a great use of the private feature, so long as ultimately, it results in delivering a public package at some point.
Note though that if you add people as collaborators, you are allowing them to manage your snap, not just install it, but upload to it too. That could be a blocker for you, depending on who the people testing are. You wouldnāt want internet randoās having publish rights to your code, I would imagine.
@popey We actually have a public package for Apache NetBeans which is public and gained some space in our Linux distribution.
Also having the hidden feature the netbeans-dev package can be public as well, the only Apache requirement is make non-released, development builds, to be pushed in the ābackgroundā. Having separate package instead of track actually helps to run the development and the release version next to each other which is really useful in testing.
The publisher was previously vetted for netbeans and the requirements are understood. Granting use of classic. This is now live.
