On Mon, Apr 7, 2014 at 10:43 AM, Josh Elser <[email protected]> wrote:
> I agree that our release "model" doesn't fully allow for a proper breadth > of "changes" to the codebase. > > My view of the current model is as Christopher described (long-term > support and bugfix); however, how it was also described by a few others, > the community wants "more" than this model provides > > And, sorry for the tangent, but I be strongly in favor of 1.7 == 2.0 for > numerous reasons, one of the biggest being this discussion. > > As far as this discussion goes, I don't think we have the ability to > maintain explicit bug-fix only (as described by "only fixes that cause > errors") since things often get refactored internally for better test > coverage, now invalidated assumptions, etc. I'd be in favor of playing > fast-and-loose for the 1.x releases how we have (keeping each other honest) > and follow an explicit model that doesn't have ambiguity in regards to > interpretation for 2.0 (what is now 1.7). Another argument for trying to better define the 1.[456].[0-9] release going forward is saving our own time. We will be living with these lines for a while. Continually debating each change that goes into them is a complete waste of our time. > > > On 4/4/14, 7:53 PM, Sean Busbey wrote: > >> None of our previous 1.x releases met semver's requirements for a minor >> version, so I don't think we need to worry about adopting that approach as >> a part of the 1.6.0 release cycle. >> >> There are a ton of reasons I want a 2.0.0. Given the significance of that >> change I think we should have a discussion about reqs. >> >> It's out of scope for this thread though. >> >> >> On Fri, Apr 4, 2014 at 6:46 PM, Christopher <[email protected]> wrote: >> >> It's probably true that 1.6.0 currently would not meet semver's >>> requirements for minor release compatibility, but something like this >>> I think should probably change at the beginning of a dev cycle, not at >>> the end. It seems to me that 1.7.0 would be the time to apply this, >>> considering it 1) has a different minimum JDK version, and 2) is >>> expected to contain a drastically improved client API module, where we >>> could actually apply maven plugins to ensure public API versioning >>> compliance naturally. >>> >>> -- >>> Christopher L Tubbs II >>> http://gravatar.com/ctubbsii >>> >>> >>> On Fri, Apr 4, 2014 at 11:48 AM, <[email protected]> wrote: >>> >>>> I don't know the specifics of the api changes in 1.6.0. But I would be >>>> >>> curious, if we applied the rules of something like semver, if the version >>> of code in the 1.6.0 branch is not consistent with the 1.6.0 version >>> number, but is maybe a 2.0.0. >>> >>>> >>>> - Dave >>>> >>>> ----- Original Message ----- >>>> >>>> From: [email protected] >>>> To: [email protected] >>>> Sent: Thursday, April 3, 2014 6:59:44 PM >>>> Subject: RE: [DISCUSS] Bugs-only strictness for bugfix releases >>>> >>>> >>>> I like the idea of what semver defines (and provides in maven plugins). >>>> I >>>> don't think we are following this methodology today. I think people have >>>> >>> a >>> >>>> tendency to want to backport or add features to patch releases because >>>> of >>>> the long running release cycles (I know I have). If we could get the >>>> testing/release cycle to be faster, then we could put out more minor and >>>> patch releases and not have long running releases. The other problem is >>>> users that are stuck on a particular version. They want the patches, but >>>> >>> not >>> >>>> the api changes. If we could tell our consumers that 1.7 will be client >>>> >>> api >>> >>>> compatible with 1.6, then users will likely upgrade faster and we will >>>> >>> have >>> >>>> less pressure to backport features to a minor/patch release. >>>> >>>> +1 to the main idea of this thread, but I think "bug only" strictness >>>> for >>>> patch releases will be the positive side effect of faster >>>> >>> testing/releases >>> >>>> and adopting some specification like semver. >>>> >>>> - Dave >>>> >>>> -----Original Message----- >>>> From: [email protected] [mailto:[email protected]] On Behalf Of >>>> Christopher >>>> Sent: Thursday, April 03, 2014 3:45 PM >>>> To: Accumulo Dev List >>>> Subject: Re: [DISCUSS] Bugs-only strictness for bugfix releases >>>> >>>> I don't think that's it's quite true to say '1.major.minor' is our de >>>> >>> facto >>> >>>> scheme. Once again, I think many of us have always viewed it as >>>> '1.long-term-support.bugfix'. >>>> >>>> -- >>>> Christopher L Tubbs II >>>> http://gravatar.com/ctubbsii >>>> >>>> >>>> On Thu, Apr 3, 2014 at 3:39 PM, Bill Havanki <[email protected] >>>> > >>>> wrote: >>>> >>>>> I agree with Christopher in principle, but I share Sean's concern >>>>> about the versioning situation. Right now, the *de facto* versioning >>>>> scheme is 1.major.minor. We should just adopt semantic versioning (or >>>>> similar) and then enforce bugs-only for bugfix releases. This gives us >>>>> >>>> the >>> >>>> room we need. >>>>> >>>>> For reference: semver.org >>>>> >>>>> >>>>> On Thu, Apr 3, 2014 at 3:24 PM, Sean Busbey >>>>> <[email protected]>wrote: >>>>> >>>>> -1 >>>>>> >>>>>> Until we have a full discussion on compatibility and what we're going >>>>>> to mean for version numbers, this is counter productive to our >>>>>> volunteer-driven CtR process. That some of us choose to focus our >>>>>> resources on more recent major versions is irrelevant. >>>>>> >>>>>> Right now, we conflate minor and bugfix versions. This change would >>>>>> mean instead conflating our major and minor versions. That's going to >>>>>> make it harder for people to upgrade for compatible improvements >>>>>> because the inclusion of the major changes will be disruptive. >>>>>> >>>>>> We need to have the compatibility and versioning discussion. This >>>>>> band aid won't help. >>>>>> >>>>>> >>>>>> On Thu, Apr 3, 2014 at 2:16 PM, John Vines <[email protected]> wrote: >>>>>> >>>>>> +1 >>>>>>> >>>>>>> >>>>>>> On Thu, Apr 3, 2014 at 2:15 PM, Christopher <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>> JIRA JQL: >>>>>>>> 'project = ACCUMULO AND resolution = Unresolved AND type not in >>>>>>>> (Sub-task, Bug) AND fixVersion in (1.4.6,1.5.2,1.6.1)' >>>>>>>> >>>>>>>> There are 32 outstanding issues not marked as "Bugs" planned for >>>>>>>> bugfix releases. This seems inappropriate to me. I would prefer >>>>>>>> to be very strict about the right-most segment of a version >>>>>>>> number, by defining it as "for bugfix releases", and by following >>>>>>>> the rule: if the issue doesn't fix a bug, then it doesn't go in a >>>>>>>> bugfix release. >>>>>>>> >>>>>>>> This strictness could help us focus on fixing and supporting >>>>>>>> actual bugs in previous releases, without being bogged down by >>>>>>>> non-bugs, it could help focus improvements in the latest version >>>>>>>> and encourage more rapid releases, and give users more reasons to >>>>>>>> upgrade. It would also help stabilize previous releases, by >>>>>>>> avoiding the introduction of new bugs, which bodes well for >>>>>>>> >>>>>>> long-term >>> >>>> support. >>>>>>>> >>>>>>>> I know we've previously talked about semver and other strict >>>>>>>> versioning schemes, but regardless of whether we do any of those >>>>>>>> other things, I think this strictness is the very least we could >>>>>>>> do, and we could start encouraging this strictness today, with >>>>>>>> minimal impact. >>>>>>>> All it would take is to define the last segment of the versioned >>>>>>>> releases as "for bugfix releases", regardless of defining the >>>>>>>> rest of the version number (which can be discussed separately, >>>>>>>> and this is a subset of most any versioning scheme we've discussed >>>>>>>> already). >>>>>>>> >>>>>>>> The implication is that some things we've done in the past to >>>>>>>> "backport" improvements and features, which didn't address a bug, >>>>>>>> would no longer be permitted. Or, at the very least, would have >>>>>>>> been highly discouraged, or would have warranted a vote (see next >>>>>>>> paragraph). >>>>>>>> >>>>>>>> As with anything, there may be important exceptions, so perhaps >>>>>>>> with this strictness about "bugfix only for bugfix releases", we >>>>>>>> could encourage (by convention, if not by policy) calling a vote >>>>>>>> for non-bugfix changes, and rely on the veto for enforcement if a >>>>>>>> non-bugfix was applied to a bugfix version. If we agree to this >>>>>>>> strictness as a community, knowing a particular change is likely >>>>>>>> to result in a veto can be a big help in discouraging violations. >>>>>>>> >>>>>>>> As a final note, I should mention that there are at least a few >>>>>>>> of us who have been thinking about this last segment of the >>>>>>>> version as "bugfix only" anyways, if only informally. The lack of >>>>>>>> formalization/strictness about this, though, has permitted some >>>>>>>> things in the past that are probably not the best ideas in terms >>>>>>>> of stability and long-term support of previous release lines. >>>>>>>> Hopefully, by adopting this strictness as a community, instead of >>>>>>>> just informally in a few of our heads, we can all get on the same >>>>>>>> page, and it will make the project better overall. >>>>>>>> >>>>>>>> -- >>>>>>>> Christopher L Tubbs II >>>>>>>> http://gravatar.com/ctubbsii >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> // Bill Havanki >>>>> // Solutions Architect, Cloudera Govt Solutions // 443.686.9283 >>>>> >>>> >>>> >>> >> >> >>
