Separately from release 1.0, I think Hop should be considering graduation. A reminder of the process: the community decides that they are ready to graduate, passes a vote, the Incubator has a discussion and a vote, then submits a motion for the next Board meeting.
I am glad that we are keeping releases separate from graduation. But “Apache Hop 1.0” sounds a bit more impressive than “Apache Hop 1.0 (Incubating)”. Just saying. ;) Julian > On Sep 10, 2021, at 7:47 AM, Matt Casters <[email protected]> > wrote: > > Hi Hops! > > The list of tickets > <https://issues.apache.org/jira/projects/HOP/versions/12350233> for 1.0 > seems to be getting shorter every day so I think it's time to release our > iconic 1.0 lest we want to end up in a Duke Nukem Forever scenario. > > Anyway, Hop is looking fantastic and I detect some pressure left and right > to dig in again with new and bigger features and improvements. Doing those > on 1.0 seems like a bad idea. Let's cut a 1.0 release instead somewhere > next week and move the master snapshot version to 1.1.0 > > I would propose to do the sensible and simple thing and release minor > versions going forward in a Major.Minor.Patch version naming scheme. I > know a lot of other projects like Beam only release patch level 0 but it > doesn't hurt to have it just in case we make a horrible mistake > <https://issues.apache.org/jira/browse/VFS-807> along the way. > > The major versions I would reserve for the larger architectural changes and > in fact I wouldn't wait too long to start working on 2.x with support for > Java 11. > > As far as compatibility is concerned I would first and foremost focus on > the Hop execution engines on existing metadata. The integration tests are > our best friends. Java API changes shouldn't concern us too much unless > they occur in the core of our stack and IMO are of lesser importance for > plugins. > > Ideas for making noise about 1.0 are also welcome! > > Cheers, > Matt
