Snapshots are ok for that, in particular since there is no strong activity in tomee these days so the snapshot is "stable". It avoids the mess to fork a project. It created issues with quartz and openjpa by the past when we did so not sure users like that much at the end.
Very worse case we can push snapshots with a particular version like 8.0.0-SNAPSHOT-xxxx to mark them even more. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le dim. 30 sept. 2018 à 03:02, Roberto Cortez <radcor...@yahoo.com.invalid> a écrit : > I think we should do a big push to have TomEE 8 out before Oracle Code One. > > With that said, we don’t have much time left, and since we still need to > wait for a vote on BVal and TomEE I was trying to cut some time from the > TomEE release if people would look at it now, and then when BVal is ready > it should only be a matter of making the actual release. > > Cheers, > Roberto > > > On 30 Sep 2018, at 01:08, David Blevins <david.blev...@gmail.com> wrote: > > > > Agreed. If there's something that can be done to help them and the time > to do it fits in the target window, that should be the first attempt. > > > > In a rare case a project may even accept help for the actual release. > WebServices project made me committer in 2006 so I could cut Axis 1.4 that > was needed by Geronimo 1.1. I've only experience that once, however. > > > > > > -- > > David Blevins > > http://twitter.com/dblevins > > http://www.tomitribe.com > > > >> On Sep 29, 2018, at 3:01 PM, Mark Struberg <strub...@yahoo.de.INVALID> > wrote: > >> > >> The primary way should imo ALWAYS to help the other projects we rely on > to get the releases out. > >> Falling back on a tomee internal release is only a last effort if the > other projects are not responsible. > >> > >> LieGrue, > >> strub > >> > >> > >>> Am 28.09.2018 um 23:50 schrieb David Blevins <david.blev...@gmail.com > >: > >>> > >>>> On Sep 28, 2018, at 3:00 AM, Roberto Cortez > <radcor...@yahoo.com.INVALID> wrote: > >>>> > >>>> While we wait for the official BVal release, I plan do create a > preview release of TomEE 8 so we can start trying it out and hopefully > speed up the process. Please, let me know if anyone has any feedback. > >>> > >>> As a community we've done ad-hoc releases other projects on a frequent > basis when best case scenario (they release their code) doesn't pan out. > >>> > >>> I doug around to try and refresh my own memory. > >>> > >>> Pre-2013 we would use svn as a maven repo and push builds in with the > version number suffixed with the svn version indicating the source. The > groupIds were left the same: > >>> > >>> - > https://svn.apache.org/viewvc/openejb/repo/org/apache/xbean/?pathrev=1432803 > >>> > >>> This meant we had to include > https://svn.apache.org/repos/asf/openejb/repo/ as a repository in the > TomEE/OpenEJB pom.xml so we could release. When the project was renamed to > tomee and that path changed to > https://svn.apache.org/repos/asf/tomee/repo/ all those old builds broke. > >>> > >>> Post-2013 we would copy the source into our section of svn, update the > groupId to ours with ".patch" appended, then add "nonfinal-<svnrevision>" > to the version number and release it to mvn central. > >>> > >>> - svn log -v http://svn.apache.org/repos/asf/tomee/deps | less > >>> - > https://mvnrepository.com/artifact/org.apache.openejb.patch/openjpa-kernel/2.4.0-nonfinal-1598334 > >>> > >>> This would be done as part of the TomEE release that needed them, such > that the Nexus staging repo contained both TomEE 1.2.3 and say OpenJPA > 2.4.0-nonfinal-1598334. When the project voted, it'd be voting on all the > binaries. In your case it would be TomEE, BVal and Geronimo validation > spec. > >>> > >>> You could potentially do a separate vote for BVal and Geronimo > validation spec. If the project's get their releases up for a vote, great > we use those releases for TomEE 8. If not, we have something to fall back > on. The benefit of this is you would not have to keep rerolling these two > each time you have to reroll TomEE 8 release binaries. I swore we did this > once, but I couldn't find the vote thread as I don't recall exactly what > artifact it was. > >>> > >>> Anyway, hope this helps. It likely should be added to our release > process documentation. > >>> > >>> > >>> -David > >>> > >> > > > >