Hi Paul,
sounds like a good idea.
You could put
* If the change can't be totally hidden, start a discussion in the
dev/users mailing list as appropriate to investigate usages of the
API by others.
* If the change can't be totally hidden, do mark the related JIRA
issue (create one if needed) with the `breaking` label.
* If the change can't be totally hidden, do add a little
summary/migration note in the relevant release note(s).
as sub-bullets to a "If the change can't be totally hidden:" bullet.
Also adding a section on how to bring the Groovy you have checked out
locally to the exact same state as the current master would imho be
helpful (to avoid "this branch is X commits ahead, Y commits behind")*
Cheers,
mg
*While Git is no doubt powerful, it is also an versioning assembler,
i.e. to people who are not used to it it is not very user friendly, and
it is annoying to have to spend time getting Git to do simple things, if
you have some time on your hands which you would rather spend improving
Groovy.
To get the local copy to be identical to the current master I found that
the following solution (which can readily be found on the internet) did
only work for simple cases:
git checkout master
git pull --rebase upstream master
git push --force-with-lease origin master
Finally this solution, seemed to work every time (since I am truly no
expert, this might be partially nonsensical or there could be a much
simpler way):
git checkout master
git fetch upstream
git checkout master
git reset --hard upstream/master
git push origin master --force
(Apologies if this has been improved in Git/GitHub since I last checked,
and no longer poses any problem.)
On 11/03/2020 06:14, Paul King wrote:
Hi everyone,
To make it easier for developer/committer on-boarding, I thought I
would try to collect some developer guidelines in one spot:
https://groovy.apache.org/guidelines.html
Please feel free to add to it or let me know if you think there is a
better way to do it.
Cheers, Paul.
