codehaus


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: HEADS-UP ActiveMQ artemis 2.6.4 release


I was going to release today, however these tests are failing on the
2.6.x branch:


org.apache.activemq.artemis.tests.integration.management.QueueControlTest.testGetMessagesAdded[durable=false]
org.apache.activemq.artemis.tests.integration.openwire.OpenWireGroupingTest.testGrouping[core-send=true
core-receive=true]
org.apache.activemq.artemis.tests.integration.openwire.OpenWireGroupingTest.testGrouping[core-send=false
core-receive=true]
org.apache.activemq.artemis.tests.integration.openwire.cluster.TemporaryQueueClusterTest.testClusteredQueue




On Tue, Dec 18, 2018 at 6:21 AM Christopher Shannon
<christopher.l.shannon@xxxxxxxxx> wrote:
>
> I agree that 2.7.0 can wait until January at this point because of the
> holidays coming up for a lot of people however it is way past due in my
> opinion.
>
> In general I would like to see Artemis released much more frequently than
> it currently is.  Artemis is very active with constant new features and bug
> fixes so we should be releasing consistently to get things out there so
> people can use them.  With as much stuff going into it every day we could
> probably do something like a monthly release and have plenty to show for it.
>
> I don't really see a reason to hold up a release for any new feature (bug
> fixes are different of course) because there are already so many features
> that are done that haven't been released.  For example, I added support for
> changing the defaultConsumerWindowSize per address back in October and at
> least 3 people have asked about that feature and I keep having to tell them
> it's not out yet.
>
> If AMQP large message support isn't quite ready then no big deal...you just
> put it into 2.8.0 and release it relatively soon after.  There's no reason
> a feature has to be tied to a specific version when you can always just
> increase the version number by 1 (the exception being breaking changes
> obviously and major things that would make more sense in a major version
> number change)
>
> On Mon, Dec 17, 2018 at 1:43 PM Clebert Suconic <clebert.suconic@xxxxxxxxx>
> wrote:
>
> > Thanks.  i had a heads up before on another thread but I couldn’t do
> > because of my workload on the task I was working on.
> >
> >
> > I will cut today and the vote thread sent tomorrow morning or later
> > tonight.
> >
> > I personally want 2.7.0 out early next year.  I will work proactively on
> > that (and welcome anyone’s help on that)
> >
> > It would be nice to have large message streamed in AMQP as we convert to
> > core right now. That’s the main thing I held a 2.7.0 release before.  If I
> > can’t do it I will still do it.  But if anyone is willing to help here it
> > would be awesome.
> >
> >
> > On Mon, Dec 17, 2018 at 11:57 AM Robbie Gemmell <robbie.gemmell@xxxxxxxxx>
> > wrote:
> >
> > > I'd say it has already been too long since the last one so I wouldnt
> > > wait until next year. A heads up is nice, and somewhat required when
> > > its been a long cycle and especially so if previous heads up have been
> > > missed. In this case I'd personally say it would be fine to proceed
> > > even later today if it seems ready and noone specifically objects, so
> > > it is out before people start to disappear for holidays. Other
> > > versions numbers are still available if anyone needs to do another
> > > release after.
> > >
> > > Robbie
> > >
> > > On Mon, 17 Dec 2018 at 16:03, Clebert Suconic <clebert.suconic@xxxxxxxxx
> > >
> > > wrote:
> > > >
> > > > Would be too bad if I cut this tomorrow? So we have time for a vote
> > > before
> > > > the Christmas week.  Or anyone would rather have it next year ?
> > > >
> > > > I had promised few weeks back but i was busy with a big chunk of work
> > > > around performance on AMQP.
> > > > --
> > > > Clebert Suconic
> > >
> > --
> > Clebert Suconic
> >



-- 
Clebert Suconic