Proposal: Prepare ICE 3 Release?

[dbluhm]

From my email sent out to the ICE dev mailing list:

With the recent batch of updates and merged pull requests, the ICE 3 "next" branch has reached a high level of stability and I would like to propose that we start preparing an official release.

As it stands today, Eclipse ICE 3 represents a drastic rewrite of the Eclipse ICE project on the order of hundreds of thousands of lines changed or dropped. This dramatic difference is a result of a reorientation to a web-first architecture, significantly simplified and improved workflow system, a new local and remote command execution library, and annotation processor based code generation tools.

This rewrite has not yet reached the full extent of its goals but has produced a solid foundation that has already been in use (to great effect) within ICE 3 itself and in various other projects. Given that it is already in use, now seems like a good time to prepare and publish a release to Maven Central that we all can incorporate into our projects more easily.

[dbluhm]

To list off just a few tasks that I think we would need to take care of before publishing a release:

• Update documentation, both in the repo and on the Eclipse ICE wiki
  • Should we favor in-repo documentation over the Eclipse Wiki? Or the other way around? Wiki info would seem to have a higher likelihood of getting out of sync with the code given it's distance from the code.
• Re-enable CI/CD pipeline
• Smooth out rough patches in code
  • "disable" partially implemented features? (For example, typescript generation is not particularly robust at the moment and I would not be opposed to dropping that from this release and waiting for the next one)
  • Finish up the PersistenceHandler (delete methods still not generated yet)
  • Ensure we're meeting test coverage goals across the project

[jayjaybillings]

We should start with a series of release candidates. ICE 3.0-RCx for x = 1...N.

In addition to the tasks that you list above, other things that we need to finish include:

• Finishing up the Task and Workflow pieces.
• Doing all the required paperwork for the release including reviewing our dependencies, handling any CQs, and preparing the release reviews.

To answer your question about documentation, we should prefer in-repo documentation and start removing articles from the wiki that are out of date or redirect them to the new in-repo article.

If we go through a series of RCs, Typescript generation does not have to be in the first set, but I think having some sort of UI generation capability is necessary to say that this version of the product fully replaces the 2.x line. My vision was also to have this be done through Typescript/Javascript.

N.B. - Doing a release will not be fast. We can do a partial release/release candidate relatively quickly, but getting everything we need done for the full release will likely be an effort of several months. Re-establishing our release cadence through this exercise though will be very valuable and timely.

[dbluhm]

To add to the list:

• Archetype generator for annotation processor ready to use our annotation tools.