Thank you Neil for your insights!
That minor thought of checking regexp-s, made me a bit worried, so I'd
use something else than release or anything containing release.
The best name I came up so far is: delivery
If anyone would have something that fits better I'm listening.
I'd like to add the signature Snapshot next to the version bump then on
master. Also if you and Jaroslav could help me detailing what would you
have as signature test that would be great.
I'd let this thread float for one day for others to chime in, then start
a vote with lazy consensus on the modified process.
See my other responses in-line.
On 10/3/20 9:44 AM, Neil C Smith wrote:
On Sat, 3 Oct 2020 at 16:44, Laszlo Kishalmi <laszlo.kisha...@gmail.com> wrote:
So it has not died in my mind, but it is the time to bring up what's on
my mind.
Thanks! Generally seems a good plan from my point of view - few
comments below. No secret I probably prefer keeping master as the
release branch, but not going to -1 this in the Lazy Consensus thread
when you're ready for that. The existing schedule and amendments to
it have been done that way, so do think we need to continue with that
process though.
- create branches: release and release122 from master
I hadn't considered this option, and the regular merges from release
to master. This way of handling fixes does address most of my
concerns about ensuring fixes are always included in master branch /
following release, as well as potential duplication of a lot of PR
effort.
Minor thought - double check any regexes in the build to match release
branches doesn't mind that branch name. May be safer to use something
other than release.
- Merge the version bump PR to master
- Merge the branch-version bump PR to release122
...
Also I'm not sure if the version bump at the beginning of
the release mode is a good place.
Version bump for 12.2 is already done. It's the final commit in
master before freeze ends in the current process.
I would suggest version bump just on master after creation of release
branches, assuming that doesn't add issues to merging fixes.
Otherwise, keep until after release? Either way, needs to only happen
on master.
Well I assume it would cause merging issues when we bump an API version,
though that would be a special undesired case.
Same consideration to when sig test files get updated? ...
- release branch, if there is a fix wished to be seen in 12.2 put a PR
against the release branch, if possible no-API changes please
Also see comments from Jaroslav from
https://github.com/apache/netbeans/pull/2338#issuecomment-686633315
We should probably generate either the sig tests or the PR for them at
branch point for merge to all branches. That way API changes can get
proper review before release, and API problems (although not
additions?) in fixes could be highlighted.
- PR-s to the release branch shall be at least marked with the 12.2
milestone and request a review from the RM
So all fixes need a base branch of release during each release cycle?
But only one PR, one JIRA ticket, etc. because they'll be synced to
master (by you)?
Yes, that's the plan. The sync-s would be PR-s as well, like your PR-s
from master to releasexyz ones. I hope github allows that.
Possibly need to document that well. Although easy enough to change
in the PR UI, probably better to make sure the author has written and
tested against the right branch first.
Sure. Once this plan would be approved by the community.
It's a pretty tight plan, please fill-in what I've missed, argue,
correct, etc.
Best laid plans of mice .... :-) * Yes, seems tight, but a reasonable
evolution of what we've done to date. All really comes down to how
timely fixes are - August was not the best month for releasing in that
regard. Good that nb-javac looks about ready for integration prior to
freeze too - been a common delayer.
* https://youtu.be/J_7SWUK7gd0
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@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-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
