On Wednesday, November 15, 2017 at 5:00:59 PM UTC+1, Colin Alworth wrote: > > I'm about to put out a blog post with a bunch of details on how one might > port gwt-user.jar modules out (thanks to the hard work of those who have > started this effort already, especially Dan Kurka and Thomas Broyer), and > once those are ready to be consumed, we'll certainly want the various > artifacts on maven central. The goal in this is to start motivating > contributors and community members to assist in the migration work > necessary to get us within reach of a GWT 3 ecosystem. > > The topic of "where we deploy early efforts" has come up a few times > behind relatively closed doors - multiple times in steering calls, and of > course at length at GwtCon this year. So, opening it up for broad > discussion: should we expect to start pushing release to org.gwtproject.* > right away, and if not, are we encouraging individual contributors to push > to their own groupIds until we *are* ready? > > Case for org.gwtproject: "centralized" jenkins server with creds to push, > making it easy to add a project (automatically?) and get it out there so > others can use it. Might want some manual checks on what is going out (or > else whoever is responsible for the groupId will look silly if it turns out > we are shipping malware), which implies full or partial review (manual > process) of each release before pushing the button. Makes it clear right > away to people searching maven central that they have found the right new > modules, since they are all under the org.gwtproject umbrella. > > Case for individual groupIds: makes it clear to early adopters that these > are "incubator" projects, and they should probably vet them themselves, or > they are relying on the community and goodwill of other developers, and > that these migrated modules are *not* official - at least not yet. Lower > friction, gets snapshots and releases out faster. > > No matter how we go, I am certain that we'll want to push to > org.gwtproject once these modules are stabilizing and we (gwt maintainers > and contributors) are confident in the code being shipped. > > Thoughts? Which ever way we go, I'd like to see the already ready-for-use > artifacts deployed within a few days - if that is too soon for > org.gwtproject, then I think that makes the choice clear, or else who knows > how long we'll be waiting. >
I don't really have a strong opinion, except that: - IFF we go with org.gwtproject, then we should only publish 0.* versions (or possibly 1.0.0-beta-* versions). - I would also expect all projects under the org.gwtproject groupId to be hosted in the https://github.com/gwtproject GitHub organization (or gwt.googlesource.com, but I don't even know who exactly has admin rights to create new projects there) and with a first "review" step by a GWT core contributor (besides the author). So this is maybe too soon if you want to get things out "within a few days". - Fwiw, I'm happy with using JitPack for my "experiments": https://jitpack.io/#tbroyer/gwt-events, https://jitpack.io/#tbroyer/gwt-http, https://jitpack.io/#tbroyer/gwt-window, https://jitpack.io/#tbroyer/gwt-history (fwiw, I've been using Gradle composite builds before I pushed code to GitHub; something you can do with Maven using an ad-hoc aggregator POM) So, IMO, the steps are, in order: 1. review candidate projects (the review includes the choice of groupId and artifactId; for example, should it be org.gwtproject.event or org.gwtproject.events? gwt-event or gwt-events? or maybe just 'event' or 'events'? gwt-event-compat or gwt-compat-event? org.gwtproject.window or org.gwtproject.user.window? or just org.gwtproject?) 2. move projects to gwtproject organization 3. deploy snapshots to Sonatype OSSRH (or any other Maven repo, like BinTray/JCenter, but OSSRH is already widely used I believe); I'd expect this to be consistent across every org.gwtproject artifact. Possibly setup build.gwtproject.org to deploy snapshots automatically (but probably use Travis CI for pull requests). 4. cut pre-releases (I'd only expect us to release a 1.0 final once we get to a state where it's usable with j2cl –and this includes settling first on how artifacts should look like for j2cl; but I'm open to discussion on this, e.g. release 1.0 for gwt2 only, and a 2.0 with j2cl support, depending on the needed changes to get that support, might not be needed at all) Those steps would also apply to candidate projects from the community in the future. -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/41417eb2-43a4-419b-8282-d2ab644a42be%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
