You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Geertjan Wielenga <ge...@apache.org> on 2021/09/21 17:50:21 UTC
Postmortem 12.5
Hi all,
Here are a few observations/ideas, based on the last few releases:
1. *Release teams.* This is an idea by Neil -- let's have for each release
a team of about 5 or 6 people focused on doing specific things, e.g., let's
have at least two release managers, Eric did a really great job, in general
even greater would be two people (e.g., Neil and me) to keep in sync and
call each other once a week around the release, plus a few people to create
binaries (e.g., John McDonnell who does the Mac OS X installer), as well as
a few others (e.g., Ömer Halit Çizmeci did great work on documentation) and
a few testers dedicated to the release, e.g., one or two per operating
system. If we like this idea, who'd like to be on the 12.6 release team?
Speak up. :-)
2. *The next major release.* My proposal here is simple -- we should do
Apache NetBeans 13 whenever we have incorporated nb-javac (which we can now
legally do) completely into Apache NetBeans, not as a confusing module that
needs to be installed somewhere after startup. That will be the point where
we are fully mature and independent as a project without weirdness. 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.
3. *Release README.* We need to update the post release steps here, i.e.,
this document is gold and needs to be constantly up to date.
https://cwiki.apache.org/confluence/display/NETBEANS/Apache+NetBeans+Release+README
4. *12.6 feature freeze is less than a month away.* Who'd like to be
release manager/s for this release and, see above, who'd like to be on the
release team? In whatever capacity, Neil and myself will be on that team as
well, see the schedule below:
https://cwiki.apache.org/confluence/display/NETBEANS/Release+Schedule
Thanks, other comments and thoughts welcome.
Gj
Re: Postmortem 12.5
Posted by Michael Bien <mb...@gmail.com>.
On 23.09.21 14:59, Neil C Smith wrote:
> On Thu, 23 Sept 2021 at 13:38, Michael Bien <mb...@gmail.com> wrote:
>> If the plugin portal mechanism works ok
>> with major.minor, why change it.
> Given the current plugin portal mechanism *doesn't* work OK, then it
> would be better not to let it sway this discussion - see eg.
> https://issues.apache.org/jira/browse/NETBEANS-5064 That we serve the
> same catalog to 12.0 and 12.5 is already a problem.
if this case is common it would show that there already isn't a
major-minor distinction and would simplify the decision to move to a
rolling versioning scheme.
But if this is a single incident then this might only indicate that some
breaking php changes should have stayed in a branch a bit longer and
wait for the next major release.
>
> Given there have been incompatible updates between 12.x versions, I
> also think that's a really good argument for switching to 13, 14, 15
> in fact? Works well for the JDK!
i am fine with it. If there is no meaning in the major version number
already, it is redundant. If we can still come up with a meaning for it
- keep using it.
-michael
>
> Best wishes,
>
> Neil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Postmortem 12.5
Posted by Neil C Smith <ne...@apache.org>.
On Thu, 23 Sept 2021 at 13:38, Michael Bien <mb...@gmail.com> wrote:
> If the plugin portal mechanism works ok
> with major.minor, why change it.
Given the current plugin portal mechanism *doesn't* work OK, then it
would be better not to let it sway this discussion - see eg.
https://issues.apache.org/jira/browse/NETBEANS-5064 That we serve the
same catalog to 12.0 and 12.5 is already a problem.
Given there have been incompatible updates between 12.x versions, I
also think that's a really good argument for switching to 13, 14, 15
in fact? Works well for the JDK!
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Postmortem 12.5
Posted by Michael Bien <mb...@gmail.com>.
On 22.09.21 19:01, Ernie Rael 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...
i think this versioning scheme makes the most sense for rolling software
releases. If someone would ask me which firefox version i am using, i
wouldn't know without having to check. The only right answer is: latest
- why bother with the details. But if someone asks me what linux kernel
i am using I could reply 5.10.x. Since the fact that it is the 5.10
branch could actually matter.
In the old days major version numbers were mostly only incremented when
there was a good reason for it. For NetBeans, such good reason could be
the migration to the next java LTS release. NB 13 could have a JDK 11
code base, NB 14 a JDK 17 code base. Everything else would be update
releases (unless there are other good reasons to bump the major release
number, larger changes, like the before mentioned nb-javac, etc).
since it ultimately doesn't matter I would suggest to keep the least
disruptive versioning scheme. If the plugin portal mechanism works ok
with major.minor, why change it. Keep releasing 12.x until there is a
good reason for 13.0.
regards,
michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Postmortem 12.5
Posted by Neil C Smith <ne...@apache.org>.
On Thu, 23 Sept 2021 at 09:57, Nicola Ken Barozzi <ba...@nicolaken.com> wrote:
> IMHO, since Netbeans is mostly an IDE for Java, it would be beneficial
> for users to have the Netbeans major number be the same as the
> supported JDK release number,
Stirring the hornet's nest! :-) For better or worse, that was
explicitly rejected some time ago. (which is not to say it couldn't
be reconsidered).
> And also plan the Netbeans release train taking into account the JDK
> release train.
It already does, but possibly not in the way you mean. There is an
issue that nb-javac isn't prepared until after the JDK has a final
release. So, nb-javac for JDK 17 should land around Oct 1st in time
for 12.6 freeze in mid-Oct.
In my opinion, before nb-javac gets included in the IDE by default,
its long term sustainability and that delay needs to be addressed, as
well as the ability to work with an EA of the next JDK.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Postmortem 12.5
Posted by Nicola Ken Barozzi <ba...@nicolaken.com>.
IMHO, since Netbeans is mostly an IDE for Java, it would be beneficial
for users to have the Netbeans major number be the same as the
supported JDK release number, and other all point releases.
So, when Netbeans is fully supporting JDK17, it would be Netbeans 17,
17.1, 17.2 etc. and when it will support JDK 18 it would be Netbeans
18, 18.1, 18.2 etc.
Al least this is what I would prefer to see, as it would have simple
meaningful and clear semantics.
And also plan the Netbeans release train taking into account the JDK
release train.
Just my two cents.
On Wed, Sep 22, 2021 at 7:08 PM Geertjan Wielenga
<ge...@googlemail.com.invalid> wrote:
>
> That’s why it’s a proposal and this is where you jump in and reveal your
> thinking on the alternative of your choice.
>
> Gj
>
> On Wed, 22 Sep 2021 at 19:01, Ernie Rael <er...@raelity.com> 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).
> >
> > -ernie
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> > For additional commands, e-mail: dev-help@netbeans.apache.org
> >
> > For further information about the NetBeans mailing lists, visit:
> > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> >
> >
> >
> >
--
Nicola Ken Barozzi barozzi@nicolaken.com
- verba volant, scripta manent -
discussions get forgotten, just code remains
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Postmortem 12.5
Posted by Geertjan Wielenga <ge...@googlemail.com.INVALID>.
That’s why it’s a proposal and this is where you jump in and reveal your
thinking on the alternative of your choice.
Gj
On Wed, 22 Sep 2021 at 19:01, Ernie Rael <er...@raelity.com> 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).
>
> -ernie
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
Re: Release numbers, ranges, semantic versioning, etc. was:Postmortem 12.5
Posted by Geertjan Wielenga <ge...@googlemail.com.INVALID>.
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 <
geertjan.wielenga@googlemail.com> 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 <ch...@gmx.net>
> 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: dev@netbeans.apache.org
>> 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 <ch...@gmx.net>
>> 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 <ch...@gmx.net>
>> > 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
>> > > ebresie@gmail.com
>> > >
>> > >
>> > > On Sat, Sep 25, 2021 at 2:48 AM Jaroslav Tulach <
>> > jaroslav.tulach@gmail.com
>> > > >
>> > > 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: dev-unsubscribe@netbeans.apache.org
>> > > > For additional commands, e-mail: dev-help@netbeans.apache.org
>> > > >
>> > > > For further information about the NetBeans mailing lists, visit:
>> > > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>> > > >
>> > > >
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>>
>>
Re: Release numbers, ranges, semantic versioning, etc. was:Postmortem 12.5
Posted by Geertjan Wielenga <ge...@googlemail.com.INVALID>.
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 <ch...@gmx.net>
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: dev@netbeans.apache.org
> 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 <ch...@gmx.net>
> 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 <ch...@gmx.net>
> > 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
> > > ebresie@gmail.com
> > >
> > >
> > > On Sat, Sep 25, 2021 at 2:48 AM Jaroslav Tulach <
> > jaroslav.tulach@gmail.com
> > > >
> > > 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: dev-unsubscribe@netbeans.apache.org
> > > > For additional commands, e-mail: dev-help@netbeans.apache.org
> > > >
> > > > For further information about the NetBeans mailing lists, visit:
> > > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
AW: Release numbers, ranges, semantic versioning, etc.
was:Postmortem 12.5
Posted by Christian Lenz <ch...@gmx.net>.
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: dev@netbeans.apache.org
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 <ch...@gmx.net> 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 <ch...@gmx.net>
> 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
> > ebresie@gmail.com
> >
> >
> > On Sat, Sep 25, 2021 at 2:48 AM Jaroslav Tulach <
> jaroslav.tulach@gmail.com
> > >
> > 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: dev-unsubscribe@netbeans.apache.org
> > > For additional commands, e-mail: dev-help@netbeans.apache.org
> > >
> > > For further information about the NetBeans mailing lists, visit:
> > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> > >
> > >
> > >
> > >
> >
> >
>
>
Re: Release numbers, ranges, semantic versioning, etc. was:Postmortem 12.5
Posted by Geertjan Wielenga <ge...@googlemail.com.INVALID>.
THE Java IDE? Where did I post that?
Gj
On Mon, 27 Sep 2021 at 13:32, Christian Lenz <ch...@gmx.net> 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 <ch...@gmx.net>
> 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
> > ebresie@gmail.com
> >
> >
> > On Sat, Sep 25, 2021 at 2:48 AM Jaroslav Tulach <
> jaroslav.tulach@gmail.com
> > >
> > 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: dev-unsubscribe@netbeans.apache.org
> > > For additional commands, e-mail: dev-help@netbeans.apache.org
> > >
> > > For further information about the NetBeans mailing lists, visit:
> > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> > >
> > >
> > >
> > >
> >
> >
>
>
AW: Release numbers, ranges, semantic versioning, etc.
was:Postmortem 12.5
Posted by Christian Lenz <ch...@gmx.net>.
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 <ch...@gmx.net>
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
> ebresie@gmail.com
>
>
> On Sat, Sep 25, 2021 at 2:48 AM Jaroslav Tulach <jaroslav.tulach@gmail.com
> >
> 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: dev-unsubscribe@netbeans.apache.org
> > For additional commands, e-mail: dev-help@netbeans.apache.org
> >
> > For further information about the NetBeans mailing lists, visit:
> > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> >
> >
> >
> >
>
>
Re: Release numbers, ranges, semantic versioning, etc. was:Postmortem 12.5
Posted by Geertjan Wielenga <ge...@googlemail.com.INVALID>.
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 <ch...@gmx.net>
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
> ebresie@gmail.com
>
>
> On Sat, Sep 25, 2021 at 2:48 AM Jaroslav Tulach <jaroslav.tulach@gmail.com
> >
> 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: dev-unsubscribe@netbeans.apache.org
> > For additional commands, e-mail: dev-help@netbeans.apache.org
> >
> > For further information about the NetBeans mailing lists, visit:
> > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> >
> >
> >
> >
>
>
AW: Release numbers, ranges, semantic versioning, etc.
was:Postmortem 12.5
Posted by Christian Lenz <ch...@gmx.net>.
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
ebresie@gmail.com
On Sat, Sep 25, 2021 at 2:48 AM Jaroslav Tulach <ja...@gmail.com>
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: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
Re: Release numbers, ranges, semantic versioning, etc. was:
Postmortem 12.5
Posted by Eric Bresie <eb...@gmail.com>.
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
ebresie@gmail.com
On Sat, Sep 25, 2021 at 2:48 AM Jaroslav Tulach <ja...@gmail.com>
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: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
Release numbers, ranges, semantic versioning, etc. was: Postmortem 12.5
Posted by Jaroslav Tulach <ja...@gmail.com>.
> >> 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: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Postmortem 12.5
Posted by Ernie Rael <er...@raelity.com>.
On 9/22/2021 10:16 AM, Scott Palmer wrote:
>> On Sep 22, 2021, at 1:01 PM, Ernie Rael <er...@raelity.com> 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: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Postmortem 12.5
Posted by Scott Palmer <sw...@gmail.com>.
> On Sep 22, 2021, at 1:01 PM, Ernie Rael <er...@raelity.com> 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?
If we want version numbers to be meaningful, 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: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Postmortem 12.5
Posted by Ernie Rael <er...@raelity.com>.
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).
-ernie
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Re: Postmortem 12.5
Posted by Eric Bresie <eb...@gmail.com>.
+1
Eric Bresie
Ebresie@gmail.com (mailto:Ebresie@gmail.com)
> On September 22, 2021 at 10:23:08 AM CDT, Neil C Smith <neilcsmith@apache.org (mailto:neilcsmith@apache.org)> wrote:
> On Wed, 22 Sept 2021 at 16:15 (x-apple-data-detectors://4), Eric Barboni <skygo@apache.org (mailto:skygo@apache.org)> wrote:
> > Up to be part of the team.
>
> Great!
>
> > And we need something for travis otherwise the restart job button will break at some point :D
>
> I've often joked the primary role of the RM is hitting that button!
> :-) It's getting beyond funny though - we need a serious review of
> what testing we need and when. We're already using a good chunk of
> ASF's Travis, GitHub Actions, etc. resources - it would be better then
> if red and green were things we could actually rely on.
>
> Neil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org (mailto:dev-unsubscribe@netbeans.apache.org)
> For additional commands, e-mail: dev-help@netbeans.apache.org (mailto:dev-help@netbeans.apache.org)
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
Re: Postmortem 12.5
Posted by Neil C Smith <ne...@apache.org>.
On Wed, 22 Sept 2021 at 16:15, Eric Barboni <sk...@apache.org> wrote:
> Up to be part of the team.
Great!
> And we need something for travis otherwise the restart job button will break at some point :D
I've often joked the primary role of the RM is hitting that button!
:-) It's getting beyond funny though - we need a serious review of
what testing we need and when. We're already using a good chunk of
ASF's Travis, GitHub Actions, etc. resources - it would be better then
if red and green were things we could actually rely on.
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
RE: Postmortem 12.5
Posted by Eric Barboni <sk...@apache.org>.
Up to be part of the team.
And we need something for travis otherwise the restart job button will break at some point :D
Eric
-----Message d'origine-----
De : Geertjan Wielenga <ge...@apache.org>
Envoyé : mardi 21 septembre 2021 19:50
À : dev <de...@netbeans.apache.org>
Objet : Postmortem 12.5
Hi all,
Here are a few observations/ideas, based on the last few releases:
1. *Release teams.* This is an idea by Neil -- let's have for each release a team of about 5 or 6 people focused on doing specific things, e.g., let's have at least two release managers, Eric did a really great job, in general even greater would be two people (e.g., Neil and me) to keep in sync and call each other once a week around the release, plus a few people to create binaries (e.g., John McDonnell who does the Mac OS X installer), as well as a few others (e.g., Ömer Halit Çizmeci did great work on documentation) and a few testers dedicated to the release, e.g., one or two per operating system. If we like this idea, who'd like to be on the 12.6 release team?
Speak up. :-)
2. *The next major release.* My proposal here is simple -- we should do Apache NetBeans 13 whenever we have incorporated nb-javac (which we can now legally do) completely into Apache NetBeans, not as a confusing module that needs to be installed somewhere after startup. That will be the point where we are fully mature and independent as a project without weirdness. 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.
3. *Release README.* We need to update the post release steps here, i.e., this document is gold and needs to be constantly up to date.
https://cwiki.apache.org/confluence/display/NETBEANS/Apache+NetBeans+Release+README
4. *12.6 feature freeze is less than a month away.* Who'd like to be release manager/s for this release and, see above, who'd like to be on the release team? In whatever capacity, Neil and myself will be on that team as well, see the schedule below:
https://cwiki.apache.org/confluence/display/NETBEANS/Release+Schedule
Thanks, other comments and thoughts welcome.
Gj
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Postmortem 12.5
Posted by Neil C Smith <ne...@apache.org>.
On Tue, 21 Sept 2021 at 18:50, Geertjan Wielenga <ge...@apache.org> wrote:
> 1. *Release teams.* This is an idea by Neil -- let's have for each release
> a team of about 5 or 6 people focused on doing specific things, e.g., let's
> have at least two release managers, ... 4. 12.6 feature freeze is less than a month away. Who'd like to be
> release manager/s for this release
The idea you mention in 1. and the question in 4. are somewhat
mutually exclusive. My idea was to *replace* the release manager role
with an ongoing group who take on the shepherding role and understand
the release processes / infrastructure. This will need to mostly be
PMC members, as currently the release manager has to be a PMC member,
but could include others as not all jobs need permissions.
I also suggested it with almost the opposite viewpoint of people
focusing on specific things. I had to withdraw through much of 12.4
due to other commitments, Eric had issues with internet access(?) for
a period during 12.5 - life happens! If we have a small team, anyone
can step up if they're free to do a task that needs doing on any day,
without feeling like we're stepping on toes in doing so, etc.
And we set up something whereby the group can keep in sync through the
release process. Possibly an alternative mailing list here - there's
a lot of release specific conversation that should come through ASF
somehow, but is probably too high noise for dev@.
> 2. *The next major release.* My proposal here is simple -- we should do
> Apache NetBeans 13 whenever we have incorporated nb-javac (which we can now
> legally do) completely into Apache NetBeans, not as a confusing module that
> needs to be installed somewhere after startup. That will be the point where
> we are fully mature and independent as a project without weirdness. 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.
+1 to the version changing and possibly dropping the idea of LTS with it.
The other criteria for incrementing to 13 that has been discussed
previously involved dropping JDK 8 support now that JDK 17 is out.
> Thanks, other comments and thoughts welcome.
The big one for me, and I think seemed to be more of an issue at start
of 12.5. Sticking rigidly to the advertised freeze and branching
date.
We agreed a while ago to snapshot and release master from particular
dates. In my opinion, that means that the default position for all
unmerged / unready PRs is to move them to the next milestone. Then
conversations can happen to rebase on delivery if any need to be
included in the release.
That way, we're not only in a better position to get betas ready on
time, but we're not holding up the merging of PRs into master for the
next release at the same time. We're losing some of the benefits of
Laszlo's delivery branch idea.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Time for specversion bump (was: Re: Postmortem 12.5)
Posted by Neil C Smith <ne...@apache.org>.
On Wed, 22 Sep 2021, 17:43 Matthias Bläsing, <mb...@doppel-helix.eu>
wrote:
> from the release timing, I think we have the spec version bump at the
> wrong time right now.
> ...
So I suggest, that spec version increment happens as the second commit
> directly after delivery is branched of.
>
...
> Does that make sense to you?
>
Well, makes a lot of sense to me. There have been a number of conversations
about when to do this since we switched to delivery branch, and has been
some thought about whether it needs to be done at that point. This seems a
clear argument in favour.
Thanks,
Neil
Time for specversion bump (was: Re: Postmortem 12.5)
Posted by Matthias Bläsing <mb...@doppel-helix.eu>.
Hi,
from the release timing, I think we have the spec version bump at the
wrong time right now.
Here is what we do:
Once we start the release process, we create a new branch "delivery",
which will become the final release. Once "delivery" is created
"master" is open for feature work. Over time bugfixes are applied to
"delivery" and features and bugfixes go into "master". When the new
version is released, it gets tagged and "delivery" is merged into
"master" to get all bugfixes from "delivery" into "master". After that
is done, a final "spec version bump" commit is done and pushed to
"master".
While release is in the works, both "master" and "delivery" have the
same spec version and this is problematic. Consider the case, where a
new feature is merged to "master", now you want to depend on this
feature. To do this, you set your dependency version to the spec
version of the module. But on what version of the module do you depend?
On the one in master or delivery? You need the master one, but can't
specify that.
So I suggest, that spec version increment happens as the second commit
directly after delivery is branched of. That way this we get:
master
spec: 1.0
|
^
/ \
/ \
/ \
/ \
| |
| |
spec inc. |
| |
| |
master delivery
spec: 1.1 spec: 1.0
| |
| |
| release
| |
| |
+<--------+
|
master
spec: 1.1
|
As master will get all commits from delivery, the requirement, that 1.1
is a superset of 1.0 is fullfilled. If you need a new feature, you will
depend on spec version 1.1, else you use 1.0. Of course you can deliver
your new plugin only after the next version (that with spec version
1.1) is released, but you know, that so you are happy.
Does that make sense to you?
Greetings
Matthias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists