PS: Christian, you are a person.
Christian, you are the person that keeps on arguing for the need for NetBeans to focus on all language and technologies, even though everyone agrees with you. The word "the" above is the same "the" as in NetBeans being the Java IDE that keeps on giving. :-) On Mon, Sep 27, 2021 at 2:58 PM Geertjan Wielenga < [email protected]> wrote: > So, you've proven it, I did not say THE Java IDE. Indeed, it is an IDE > written in Java, in that sense it is a Java IDE. > > Gj > > On Mon, Sep 27, 2021 at 2:30 PM Christian Lenz <[email protected]> > wrote: > >> https://twitter.com/netbeans/status/1435687644705529866 >> >> I guess you are mainly behind the twitter account of NetBeans also behind >> the Facebook page of NetBeans, but sure could be someone else. But >> @netbeans still exists before Apache so. If not, I’m sry, but again someone >> tries to set the Focus wrong IMHO. >> >> Von: Geertjan Wielenga >> Gesendet: Montag, 27. September 2021 13:34 >> An: [email protected] >> Betreff: Re: Release numbers, ranges, semantic versioning, etc. >> was:Postmortem 12.5 >> >> THE Java IDE? Where did I post that? >> >> Gj >> >> On Mon, 27 Sep 2021 at 13:32, Christian Lenz <[email protected]> >> wrote: >> >> > That doesn’t matter if you set the focus back to Java more and more. You >> > post about NetBeans as THE Java IDE. What is your goal with that? Next >> time >> > you will post about „NetBeans now has a new Version politic which is in >> > line with new JDK version“. Wow. >> > >> > Again, this is my pov and I’m for those versioning what we have or more >> an >> > other one with will be in line with the year like Apache NetBeans >> 2022.1 – >> > 2022.4. But we had this discussion already. >> > >> > Von: Geertjan Wielenga >> > Gesendet: Sonntag, 26. September 2021 20:20 >> > An: dev >> > Betreff: Re: Release numbers, ranges, semantic versioning, etc. >> > was:Postmortem 12.5 >> > >> > NetBeans can support all the languages and technologies of the world >> while >> > still being coupled to JDK versions... >> > >> > Gj >> > >> > On Sun, Sep 26, 2021 at 7:48 PM Christian Lenz <[email protected]> >> > wrote: >> > >> > > I don’t know why everyone is trying to pitch NetBeans back to be a >> Java >> > > IDE? It can even more. Problematic again is also the other APIs for >> > > HTML/CSS/JS they are not public by default. Everything is as stable as >> > > possible now. Make them open and let people like me contribute to the >> > other >> > > parts of the IDE. Everything is working for years now. >> > > >> > > Yes, NetBeans don’t need more Bugs but it has bugs like every other >> > > software 😃 so what will be the solution for that? Ignoring Bugs of >> > > NetBeans? Seems so. >> > > >> > > So I’m totally against to couple the version to the JDK Version. Don’t >> > set >> > > the focus back to Java to this awesome IDE. >> > > >> > > >> > > Cheers >> > > >> > > Chris >> > > >> > > Von: Eric Bresie >> > > Gesendet: Sonntag, 26. September 2021 18:44 >> > > An: Netbeans Developer List >> > > Betreff: Re: Release numbers, ranges, semantic versioning, etc. >> > > was:Postmortem 12.5 >> > > >> > > I know since Netbeans IDE is java centric, it is by no means specific >> to >> > > Java and linking to java version may be valuable to java developers >> but >> > may >> > > not be for those for other languages. >> > > >> > > Think that has been discussed before but I'm going to throw it out >> just >> > in >> > > case... >> > > >> > > Would it be worth changing the number to date based versions like >> other >> > > folks have (i.e. yyyy-mm, or some "quarterly" based nomenclature [i.e. >> > > 2021-Q3 or Q4])? >> > > >> > > Eric Bresie >> > > [email protected] >> > > >> > > >> > > On Sat, Sep 25, 2021 at 2:48 AM Jaroslav Tulach < >> > [email protected] >> > > > >> > > wrote: >> > > >> > > > > >> This essentially makes release numbers meaningless, which >> seems to >> > > be >> > > > the >> > > > > >> way things are going... >> > > > >> > > > There is a difference between "marketing" release number and >> > > "engineering" >> > > > release numbers. Marketing release numbers are meaningless - it >> doesn't >> > > > matter >> > > > whether it is going to be NetBeans 13, 14, or 12.6, 12.7 - it's >> just a >> > > > marketing campaign. >> > > > >> > > > Engineering numbers are more important when it comes to discussion >> > > whether >> > > > a >> > > > plugin works with certain system version or not. A scientific take >> on >> > > that >> > > > can >> > > > be found at my website: >> > > > >> > > > http://wiki.apidesign.org/wiki/RangeDependenciesAnalysed >> > > > >> > > > NetBeans Module System allows you to easily specify the "lower >> bound". >> > > Do >> > > > it. >> > > > There is also an implicit "upper bound" - restricted by the same >> major >> > > > release number, but Apache NetBeans project avoids changing the >> major >> > > > release >> > > > number as much as possible and rather we keep (signature based) >> > > > compatibility. >> > > > >> > > > In any case my advice is: Upload to update center. Specify the lower >> > > > bound. >> > > > Open up the "upper bound" as much as possible, unless it is known >> there >> > > is >> > > > a >> > > > problem in "future versions". In such case restrict the upper bound >> or >> > > > rather >> > > > report and fix the problem in NetBeans code itself. >> > > > >> > > > >> > > > > >> 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. >> > > > >> > > > That's result of the hard work of Apache NetBeans contributors and >> > > release >> > > > managers! Everyone pays attention to "sigtest" signatures and as >> such >> > we >> > > > don't >> > > > have linkage problems (so common in Oracle NetBeans) and even >> runtime >> > > > problems >> > > > are rare. >> > > > >> > > > >> > > > > 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. >> > > > >> > > > Repeat: marketing numbers (12.2 and 12.3) are useless. Only the >> > > > engineering >> > > > numbers make (some) sense. E.g. watch for individual module >> > dependencies. >> > > > >> > > > > The old method of tying a full version number to a plugin is more >> > > > > reliable. >> > > > >> > > > Of course. Only "no flexibility" (in version dependencies) allows >> some >> > > > form of >> > > > certification - that's the approach QA guys like. However... >> > > > >> > > > > But with 4 releases a year there's more overhead, not only for >> > > > > plugin developers, but for doing plugin verification. >> > > > >> > > > ... as we are short on time and resources, we'd rather worship >> > "semantic >> > > > versioning" and understand proximity: >> > > > http://wiki.apidesign.org/wiki/Proximity >> > > > >> > > > > 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. >> > > > >> > > > NetBeans versioning scheme has been designed before semantic >> versioning >> > > > website was created. There may be some differences, but in general, >> I >> > > > suggest >> > > > to follow semantic versioning and think about proximity. >> > > > >> > > > > 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; >> > > > >> > > > Clever. >> > > > >> > > > > 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). >> > > > >> > > > Obviously. It is desirable to offer a system when one jVi module can >> > work >> > > > with >> > > > all (released/marketing) versions NetBeans IDE since some "lower >> > bound". >> > > > >> > > > > 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. >> > > > >> > > > If you invest into pushing users to the latest version (like >> browsers >> > or >> > > > iOS >> > > > does), then you simplify the burden of supporting old versions for >> > > > everyone. A >> > > > question remains: what poor users that cannot run the latest version >> > (of >> > > > iOS >> > > > like me) shall do? >> > > > >> > > > > > 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. >> > > > >> > > > (Engineering) versioning shall remain per module. It stresses the >> idea >> > > > that >> > > > NetBeans Platform is like LEGO - you can select the pieces (that fit >> > > > together >> > > > thanks to the versioning) and assemble anything you like. >> > > > >> > > > > > 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. >> > > > >> > > > Again, 13 is a marketing number. Do whatever you want with it, but >> > don't >> > > > interchange it with engineering numbers and compatibility, please! >> > > > >> > > > -jt >> > > > >> > > > >> > > > >> > > > >> > > > >> --------------------------------------------------------------------- >> > > > 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 >> > > > >> > > > >> > > > >> > > > >> > > >> > > >> > >> > >> >>
