I think it's always ok to re-release artifacts where nothing's changed. So, how can you be blocked on another language's implementation if you simply change the version number and re-release?
-- Philip On Thu, Nov 5, 2015 at 9:43 AM Ryan Blue <b...@cloudera.com> wrote: > Phil or Sam, any ideas about how to keep release management simple, but > be able to avoid blocking specific languages on under-maintained ones? > > Also, looking at the release history we've had 3 releases in the last 2 > years, and that's being generous to include 1.7.5 that was released in > August 2013. I don't think more release overhead would be that big of a > problem, and would be well worth keeping the languages that are well > maintained released and up-to-date. > > rb > > On 10/30/2015 09:37 AM, Ryan Blue wrote: > > I think Sean is right that we could continue to release several at once. > > We would almost certainly continue this practice for several languages > > that are mostly unmaintained (like perl and php). I also expect each > > language's release cadence to reflect the activity in that language, > > which I think is very important to maintain. > > > > I also don't want to underestimate the drawback of having a single > > version for multiple implementations. We can't use semantic verisoning > > for any of the implementations. If we bump the minor version (!) because > > of a breaking change in Java, but aren't making breaking changes to C, > > this is confusing to users. > > > > If we don't separate release vehicles, how can we improve version > > conventions? > > > > And how do we ensure timely releases that aren't blocked by other > > implementations? This affects how attractive this project is to new > > contributors. If the releases are seldom and contributions aren't > > available for months at a time, I think we have a problem. > > > > rb > > > > On 10/29/2015 04:51 PM, Philip Zeyliger wrote: > >> -0. > >> > >> If you divide the world into N releases, you'll end up having to do > >> release > >> management N times. I think this will make doing releases that much > more > >> complicated, time-consuming, and error-prone. > >> > >> Note that you could separate release trains while remaining in a single > >> repo. I'd certainly prefer that than separating into many smaller > repos. > >> > >> -- Philip > >> > >> On Thu, Oct 29, 2015 at 11:31 AM Ryan Blue <b...@cloudera.com> wrote: > >> > >>> On 10/29/2015 11:28 AM, Sean Busbey wrote: > >>>> On Oct 29, 2015 1:19 PM, "Ryan Blue" <b...@cloudera.com> wrote: > >>>> > >>>> Where would the language interop tests live if we don't break them > out? > >>>> > >>>> (We already have interop tests, in case that was lost in my original > >>> email.) > >>> > >>> We could either keep them where they are or add a separate repo. > Running > >>> them with a release candidate would have to be part of the release > >>> checks. > >>> > >>> rb > >>> > >>> > >>> -- > >>> Ryan Blue > >>> Software Engineer > >>> Cloudera, Inc. > >>> > >> > > > > > > > -- > Ryan Blue > Software Engineer > Cloudera, Inc. >
