neilcsmith-net commented on PR #8206: URL: https://github.com/apache/netbeans/pull/8206#issuecomment-2650329991
I would _prefer_ having one spec version increment per API release, but not enough to put more time into the conversation. It's not a blocker. I just don't see the point in doing this as it's not applied consistently, causes _minor_ headaches (not a problem, lots of things do), but primarily doesn't tell you anything useful. > While reverting API changes might be more tricky, reverting API changes is inevitably tricky. Reverting anything prior to release is fairly simple. Reverting API after a release is generally a no-go. VSNetBeans interim releases are ignored there. The spec version in the previous PR of this told you nothing. That spec version now corresponds to a different API. An API that is tested for breakage via CI. Each spec version being a snapshot of released API makes sense to me. Anything else is in flux and cannot be relied upon, including currently by VSNetBeans. We have previously reverted features that have been released solely in VSNetBeans. The question of whether spec versions need to be relevant to VSNetBeans, as in API's are fixed at each VSNetBeans branch point, as @mbien alludes to above, then needs to be discussed ... but not on this PR. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@netbeans.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: notifications-unsubscr...@netbeans.apache.org For additional commands, e-mail: notifications-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
