Hi Julian, François, We absolutely hear you. Based on the feedback we get, we'll need both a 1.0 release and graduation to fuel an increased adoption of Hop.
Our idea is to release 1.0, quickly followed by the start of the graduation process. Of course "Apache Hop 1.0" sounds better than 'Apache Hop (Incubating) 1.0". On the other hand, graduating relatively quickly after releasing 1.0 doesn't sound too bad either ;-) Regards, Bart On Fri, Sep 10, 2021 at 5:12 PM Francois Papon <[email protected]> wrote: > Big +1 with Julian :) > > regards, > > François > [email protected] > [email protected] > > Le 10/09/2021 à 17:10, Julian Hyde a écrit : > > 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 >
