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
> >>>
> >>
> >
>
>

Reply via email to