You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Neil C Smith <ne...@apache.org> on 2019/09/25 11:28:45 UTC
Re: Aligning implementation and specification versions?
On Sun, 25 Aug 2019 at 19:06, Jesse Glick <ty...@gmail.com> wrote:
> A long time ago I wrote up
> http://wiki.netbeans.org/NbmPackageStability to discuss problems with
> the versioning scheme in NB and propose a different system. At this
> point I would say that the proposed change is unnecessarily complex,
> and that better development practices would avoid most problems:
Missed this reply at the time - just found it looking for this thread.
I like the proposal you wrote, and argued for considering it when
there was a vote a while back on what to do with friend dependencies.
Not that that vote really led to much conclusive. I personally
probably agree with your assessment on the complexity, and the
suggestions seem good - in particular
> · Use simple specification version dependencies, and mark all packages
> public which you would expect any other modules to refer to.
... yes, please let's just do this for NB 11.3 in preparation for next
LTS! The active PRs to add friend access for third-party plugins are
just wrong on so many levels. Let's keep friends only for the
minority of legitimate cases where a module has optional extensions
that need to be separate.
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: Aligning implementation and specification versions?
Posted by Jaroslav Tulach <ja...@gmail.com>.
Create a PR to make the API public!
-jt
Odesláno z iPadu
> 3. 10. 2019 v 3:31, Tim Boudreau <ni...@gmail.com>:
>
> +1 - I recently found that to have a preview for a formatter requires a
> friend dependency, which is ridiculous given that the API has not changed
> in many years.
>
> -Tim
>
>> On Wed, Sep 25, 2019 at 7:29 AM Neil C Smith <ne...@apache.org> wrote:
>>
>>> On Sun, 25 Aug 2019 at 19:06, Jesse Glick <ty...@gmail.com> wrote:
>>> A long time ago I wrote up
>>> http://wiki.netbeans.org/NbmPackageStability to discuss problems with
>>> the versioning scheme in NB and propose a different system. At this
>>> point I would say that the proposed change is unnecessarily complex,
>>> and that better development practices would avoid most problems:
>>
>> Missed this reply at the time - just found it looking for this thread.
>> I like the proposal you wrote, and argued for considering it when
>> there was a vote a while back on what to do with friend dependencies.
>> Not that that vote really led to much conclusive. I personally
>> probably agree with your assessment on the complexity, and the
>> suggestions seem good - in particular
>>
>>> · Use simple specification version dependencies, and mark all packages
>>> public which you would expect any other modules to refer to.
>>
>> ... yes, please let's just do this for NB 11.3 in preparation for next
>> LTS! The active PRs to add friend access for third-party plugins are
>> just wrong on so many levels. Let's keep friends only for the
>> minority of legitimate cases where a module has optional extensions
>> that need to be separate.
>>
>> 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
>>
>>
>>
>> --
> http://timboudreau.com
---------------------------------------------------------------------
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: Aligning implementation and specification versions?
Posted by Tim Boudreau <ni...@gmail.com>.
+1 - I recently found that to have a preview for a formatter requires a
friend dependency, which is ridiculous given that the API has not changed
in many years.
-Tim
On Wed, Sep 25, 2019 at 7:29 AM Neil C Smith <ne...@apache.org> wrote:
> On Sun, 25 Aug 2019 at 19:06, Jesse Glick <ty...@gmail.com> wrote:
> > A long time ago I wrote up
> > http://wiki.netbeans.org/NbmPackageStability to discuss problems with
> > the versioning scheme in NB and propose a different system. At this
> > point I would say that the proposed change is unnecessarily complex,
> > and that better development practices would avoid most problems:
>
> Missed this reply at the time - just found it looking for this thread.
> I like the proposal you wrote, and argued for considering it when
> there was a vote a while back on what to do with friend dependencies.
> Not that that vote really led to much conclusive. I personally
> probably agree with your assessment on the complexity, and the
> suggestions seem good - in particular
>
> > · Use simple specification version dependencies, and mark all packages
> > public which you would expect any other modules to refer to.
>
> ... yes, please let's just do this for NB 11.3 in preparation for next
> LTS! The active PRs to add friend access for third-party plugins are
> just wrong on so many levels. Let's keep friends only for the
> minority of legitimate cases where a module has optional extensions
> that need to be separate.
>
> 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
>
>
>
> --
http://timboudreau.com