Updating to the EPL-2.0 (and, by extension, the SUA 2.0) is not a simultaneous release participation requirement, it's a general requirement.
I haven't been as noisy as I should have been on this forum. Instead, I've been working with individual projects as they engage in the release process. I'd hoped that we'd have picked up everybody by now, but that clearly hasn't happened: either I've missed doing this for some projects, neglected to follow up, or those projects simply haven't engaged in a release review in a while. There has been plenty of noise about this, but certainly not enough on this channel. I'll change that.
I'll backpedal a bit then... if it is possible for this release to update from EPL-1.0 to EPL-2.0 (without adding risk to your release), then please do so. If not, add it as a plan item for your next release. If your project is not planning any releases and is still using EPL-1.0, please plan a service release for 2020-06 with the license upgrade.
While have your attention, I'll reinforce...
If you are adding new bits to 2020-03, you need to create a release record for that new release. If you have not engaged in a release review within a year of the release date, you need to schedule a release review. If you have engaged in a successful release review within one year of your release date, then you do not have to engage in a release review or submit your IP Log for review. If you are not sure whether or not your intellectual property is being properly tracked, go ahead and submit your IP Log and I'll have a look.
Are you suggesting that SUA 2.0 is a new participation
requirement? It seems to me merely a very-nice-to-have. At this
point I would just be happy if there were no corrupted variants of
SUA 1.0 and SUA 1.1:
The odds that the 20 features using SUA 1.0 and the 365 features
using SUA 1.1 will all migrate to SUA 2.0 before the 2020-03
release, without introducing new errors, seem beyond remote to me.
All,
Note that not only were the two license problems above not fixed
for M2, the signing problems were also not fixed:
Of course this is only the case after waiting some minutes for
the workspace dialog prompt, hoping my computer doesn't catch on
fire in the process, and then waiting another minute for the IDE
actually rear its ugly head.
At this point, the Error Log is very well populated:
Most interesting is that clicking an error log entry will always
create a new one:
org.eclipse.core.runtime.CoreException: No property tester
contributes a property
org.eclipse.tcf.te.launch.ui.model.canDelete to type class
org.eclipse.ui.internal.views.log.LogEntry
Regards,
Ed
On 07.02.2020 23:07, Wayne Beaton
wrote:
Hey folks!
Today is the M2 date for the simultaneous release. I'll be
assembling the project participation information shortly.
If you are planning to contribute new bits to the 2020-03
simultaneous release, and have not already done so, please
create a release record as soon as possible. It'll be much
easier for everybody (especially me) if you can get this done
before I start assembling the participation list (if the
information is there, then it will be far more likely that I
get it right the first time and we can avoid the
back-and-forth of fixing things after the fact). There is help
in the handbook.
Please make sure that your content has the latest SUA and
that, if your project is currently using the EPL-1.0, you
update to the EPL-2.0. If you need help with this, please let
me know (there's a lot of useful information for this on Bug 530393).
You need only engage in a release review if you have not
done so with one year of your release date. If you do need to
engage in a release review, please engage in the workflow at
your earliest convenience. The IP Log submission deadline is
February 28/2020 (M3).
Note that, whether or not you engage in a release review,
you are required to implement the IP Policy at all times.
Further, it is a simultaneous release requirement that all
third party content be consumed through Eclipse Orbit.
The IP Policy was updated in the fall. In practical terms
for simultaneous release participants, this means that you no
longer need to create piggyback CQs. There's more background
in a Reviewing Third Party Content blog
post. More information regarding how our processes are
being updated will be coming shortly.
You have likely heard that the Eclipse Planning Council was
removed from the Bylaws of the Eclipse Foundation. This does
not mean that the Planning Council no longer exists, only that
it is no longer governed directly by the bylaws. The Planning
Council is still very much the primary authority with regard
to oversight of the simultaneous release.
Thanks,
Wayne
--
Wayne Beaton
Director of Open Source Projects | Eclipse Foundation, Inc.