On 9/22/2021 10:16 AM, Scott Palmer wrote:
On Sep 22, 2021, at 1:01 PM, Ernie Rael <[email protected]> wrote:
On 9/21/2021 10:50 AM, Geertjan Wielenga wrote:
2. *The next major release.* [snip] From 13
onwards, maybe each release should be a major release, i.e., there are
enough numbers in the world, we don't need minor releases anymore after
that breakpoint.
This essentially makes release numbers meaningless, which seems to be the way
things are going...
There is a, perhaps, unintended consequence. The plugins I support have
continued to work, and be available in the plugin manager, through all of 12.x
without any effort on my part. The plugins are keyed to a major release number;
so IIUC, this release numbering proposal requires each plugin maintainer to
modify the update-center metadata on every release (PITA).
As a potential workaround to that PITA, the plugin mechanism can be made a bit
more loosely coupled to the version number?
The before times update center required a new plugin download for every
NB release. The netbeans.apache update center is friendlier since you
can specify which /major/ releases a plugin works with; so it's not
dependent on a NB minor release, and you can specify multiple NB
releases. But it's easily possible that going from 12.2 to 12.3 a plugin
needs to be changed, but there's no way to specify that in the update
center, for example see
https://issues.apache.org/jira/browse/NETBEANS-5064 which demonstrates
that the current association of NB-version with plugin is broken.
The old method of tying a full version number to a plugin is more
reliable. But with 4 releases a year there's more overhead, not only for
plugin developers, but for doing plugin verification.
Some way to loosely couple seems desirable. If the portal had a list of
all version numbers, and spec'ing vers-X means "vers-X and all later
releases, up to the next spec'd" would do the trick.
If we want version numbers to be meaningful,
NetBeans might the the prime example of where semantic versioning would
not work well. Each NB module has it's own version number.
jVi was compatible with NB-7.* and NB-8.*. In module restore, jVi
checked each module it cared about and set some flags to control
behavior; a hassle but easier than having different plugin versions for
each NB version, especially when it comes to features and bug fixes (I
wasn't comfortable with saying you had to use the latest NB version).
BTW, when I said "release numbers meaningless, which seems to be the way
things are going" I was referring to the industry, thinking firefox/chrome.
-ernie
I suggest an attempt at something as close as possible to semantic versioning:
https://semver.org
Then plugin compatibility can be inferred from the major version number, and if
that changes it’s because you really do need to check more than metadata to see
if your plugin remains compatible.
If NetBeans moves the required JRE/JDK to 11 or later that would make now the
time to bump the major version to 13 or later. (I would propose the second
most recent LTS release of the JDK as the maximum required version, to give
lots of time to migrate to the next LTS version.)
I do think now that JDK 17 is out there should be no requirement to stick to
Java 8 for running NetBeans - as long as NetBeans can still be used to build
applications for Java 8 without a hassle.
Cheers,
Scott
---------------------------------------------------------------------
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
