Hi Sam,
Thank you for the overview. Since you do the work, it is OK to follow your schedule and the version scheme you have defined. In my opinion the only requirement as you said: information and transparency (outside your company people should be able to follow the process and your reasoning).
For the change, I have cherry-picked the commit to the branch "e_4_5_m_3_21_x". Is that correct for the 2.10.1 service release you have described?
Can someone review this change (just a cherry pick of the already approved commit): https://git.eclipse.org/r/#/c/85465/
Thank you in advance,
Jeremie
Le 21.11.2016 21:03, Sam Davis a écrit :
Hi Jeremie, We aren't planning to release Mylyn 3.22, which includes Docs 2.11, until April 7. Unfortunately we don't have capacity to do releases "on demand." Also, the deadline for contributing our release build to Neon.2 is in two weeks so I think it's too late to start planning a full release now anyway. However, if you can backport the fix to Docs 2.10, I can try to make time to do a 2.10.1 service release and contribute that to Neon.2. How does that sound? Would you be able to do the backporting this week?
We have generally made an effort to line up Mylyn releases with Eclipse simultaneous releases when we can and this may have set up an expectation that we will release Mylyn every time there is a simultaneous release, but that should not be assumed. However, I think we should do a better job of making the community aware of release plans. The dates are visible at https://projects.eclipse.org/projects/mylyn/governance but I haven't been very good about sending out announcements about upcoming releases (partly due to lack of any response when I do send out announcements). In the future I will announce on the mylyn-dev list when we are planning to do our next release, with a link to the release bug so people can follow along.
Thanks, Sam
|