Hello, Thank you for your answers. We would appreciate if we could have minor version including this feature (if it is easy to back-port of course) because we already a use case to implement that requires this feature.
Best regards, Rabih On Wed, Feb 1, 2017 at 9:18 PM, Rob Godfrey <[email protected]> wrote: > On 1 February 2017 at 18:37, Robbie Gemmell <[email protected]> > wrote: > > > If it was considered for back port then it seems a 6.2.0 would be > > better if sticking to a strict semver format, though I wouldn't overly > > mind if it was just included in a 6.1.2 with any intended bugfixes > > either if folks really didn't want to have a 6.2.x a couple months > > before doing 7.0.0, though I don't see a huge issue with that > > personally. I also don't think it would be unreasonable to tell anyone > > that since such a 6.2.x series would be so similar to 6.1.x, renamed > > only on semver grounds for a fairly isolated feature many folks wont > > touch, that there won't be any more 6.1.x releases to cut down on the > > overhead of maintaining two almost identical release branches. > > > > I guess the main thing is really how much work it is to back port it, > > which I can't say I know. > > > > I think the work to backport from trunk to a branch from 6.1.x should be > pretty trivial. In terms of versioning, I'm probably more "liberal" in > what I would allow in a 6.1.2 release than others would be, though given > that this essentially adds (in a compatible manner) to the (REST) API > around the JDBC virtualhost(node), I can see why we would want this to be a > 6.2. > > Fundamentally using semantic versioning is supposed to help the user base, > if by using it we hold off on releasing a feature that is useful to our > userbase because it means that we worry about having too many versions, it > feels like we are doing something wrong. > > (I hate myself for suggesting this, but one *horrible* way of avoiding a > 6.2 while still adding the feature to 6.x is, I guess, simply not making > the attribute "managed" in 6.1.x, just using the context variable for the > prefix... so it can be changed by setting the context variable, but there > is no change in the API) > > -- Rob > > > > > > Robbie > > > > On 1 February 2017 at 15:17, Lorenz Quack <[email protected]> > wrote: > > > Hello Rabih, > > > > > > Unfortunately, the v7 release is still a couple of months away. > > > Out of curiosity, what is your time-line for when you would like this > > > feature to land? > > > > > > We were considering back porting this but there are currently no plans > > for a > > > 6.2.0 release and as a new feature this is not really fit for a bug fix > > > release (i.e. 6.1.2). > > > Our limited resources are currently focused on v7 but it does involve a > > fair > > > amount of work. > > > > > > Sorry that this is probably not he answer you were hoping for. > > > > > > Kind regards, > > > Lorenz > > > > > > > > > > > > On 01/02/17 14:35, Rabih M wrote: > > >> > > >> Hello, > > >> > > >> The question is in the title. > > >> I am asking because we are interested in > > >> https://issues.apache.org/jira/browse/QPID-7558 > > >> > > >> Best regards, > > >> Rabih > > >> > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
