I am going to try using the Semantic Versioning specification on my project. There is a maven plugin[2] for validation and enforcement. Reading over the specification, it seems pretty common sense and straight forward.
[1] http://semver.org/ [2] https://github.com/jeluard/semantic-versioning ----Original Message----- From: Sean Busbey [mailto:[email protected]] Sent: Wednesday, March 12, 2014 12:20 PM To: dev@accumulo apache. org Subject: Re: [DISCUSS] Accumulo Bylaw fixes We already have guidelines on the distinction between major and minor releases[1]. I agree that we would do better to have more rigorous definitions around compatibility on both. That's a discussion I've been meaning to start, but I wanted to wait until people weren't busy with 1.6.0. It sounds like we'd be better off starting earlier, but I don't know that we need that to establish that we want release managers. We can just rely on the current weak definition for major/minor. [1]: http://accumulo.apache.org/governance/releasing.html On Wed, Mar 12, 2014 at 11:15 AM, Christopher <[email protected]> wrote: > Before we establish either bylaws or guidelines which distinguish > between "major" and "minor" releases, I think we need to establish > release versioning standards first. Perhaps that discussion is a > prerequisite to this one? Personally, I think the results of that > discussion would make an excellent first amendment to the bylaws. > > -- > Christopher L Tubbs II > http://gravatar.com/ctubbsii > > > On Wed, Mar 12, 2014 at 12:09 PM, Mike Drob <[email protected]> wrote: > > Inline. > > > > On Wed, Mar 12, 2014 at 10:50 AM, Billie Rinaldi > > <[email protected]>wrote: > > > >> I disagree with Mike on point 4. This is not a matter of people > >> not > having > >> authority, and I don't see a lack of release plans / managers as > >> the problem behind our major releases not occurring as often as we'd like. > I > >> wouldn't be opposed to adding a release plan / manager vote as an > optional > >> step that can be taken when preparing for a release (perhaps a > >> strongly encouraged or even required step when it's a major release). > > > > > > In theory, I think this makes sense. Major releases are important > > enough and difficult enough that I'd really like to require a release > > manager. > In > > practice our minors tend to be pretty significant minors that still > require > > a significant amount of care and preparation, so I think release > > managers will still be useful. > > > > I also think > >> we should consider making the vote lazy consensus, falling back to > majority > >> approval if a -1 is received. > >> > > +0. I think shows stronger support if actually voted on up front, > > +but > this > > is not a deal breaker for me. Our current process is close to this > already. > > > >> > >> However, adding this step will not solve our release woes. Perhaps > >> something that might help would be to develop a set of suggested > guidelines > >> to follow or strategies to take when working towards the final > >> stages > of a > >> release, post code freeze. At least some of these should be > >> responsibilities of all committers, not just a release manager. > >> > > > > I did not mean to suggest that this was the only thing needed to > > improve our process. Simply that it is an easy solution that I > > expect to have positive outcomes. While I agree that all committers > > should be held responsible for driving towards a release, different > > people will always have different opinions on what needs to be part of any > > given release. > What > > I think is trivial, you might consider a blocker, and vice versa. > > The incomplete feature that I think needs just a little more work, > > you could think is immature and should be pulled entirely. > > Delegating authority to > a > > release manager makes these decisions simpler, while still giving us > > flexibility to write the code we each want. > > > > > >> Some guesses for what could go on this list: > >> - always select a new date when a previously selected date has > >> passed > >> > > Who is responsible for this? If dates are chosen by fiat, then they > quickly > > become meaningless. This actually sounds like a great argument _for_ > > a release manager. > > > > > >> - initiate discussion of remaining tickets / tasks regularly (every > week?) > >> > > This can be a very daunting task. > > > > > >> - once a .0-SNAPSHOT branch has been created, every committer > >> should > follow > >> some specified procedure before committing changes to it (I don't > >> mean a voting procedure, more like soul-searching -- or perhaps a > >> simple > >> flowchart: Are you committing this change against a blocker or > >> documentation-only ticket? No => Don't commit or merge it to this > branch). > >> > > Soul searching is a very fuzzy concept that I am not comfortable > > with for being used to drive releases. We've had an implicit (read: > > unwritten) policy that only bug fixes can go into release branches, > > but many developers (myself included) have stretched both the > > definition of bug > and > > the definition of fix. I'm completely on board with always making > > code better, but it's also good to draw a line in the sand somewhere > > and actually make releases. > > > >> > >> Any thoughts or other suggestions on strategies to document? > >> > > Maybe we can add some release plan/manager basics to the bylaws? > > > > """A release plan consists of: > > * a release manager > > * a proposed version number > > * a feature freeze date (bug fixes and documentation only) > > * a code freeze date (documentation only) > > * a planned rc vote date > > > > Should any of these dates be missed, the release manager is > > responsible > for > > selecting new dates.""" > > > >> > >> > >> > >> On Tue, Mar 11, 2014 at 1:20 PM, Sean Busbey > >> <[email protected] > >> >wrote: > >> > >> > Moving this over to its own DISCUSS thread so we can keep the > >> > VOTE > easier > >> > to follow. > >> > > >> > wrt #4, I'm with Mike on this. One of our big problems, as a > community, > >> is > >> > lack of steady release cadence. Even once we decide on a feature > freeze, > >> we > >> > don't have enough rigor in driving to release. For example, 1.6.0 > >> > hit feature freeze 4.5 months ago[1]. I think John is doing fine > >> > given the circumstances, but without a date to drive towards it's > >> > hard to > justify > >> > throwing stuff off the raft. > >> > > >> > Since we'll presumably be updating the bylaws for the next vote, > >> > I'd > like > >> > to see a definition for the Release Manager role since we > >> > reference > it. > >> > > >> > [1]: http://s.apache.org/accumulo_1.6.0_feature_freeze_vote > >> > > >> > -Sean > >> > > >> > On Tue, Mar 11, 2014 at 1:17 PM, Mike Drob <[email protected]> > wrote: > >> > > >> > > 1) Agree w/ Bill. > >> > > > >> > > 2) Agree w/ Bill. > >> > > > >> > > 3) In my understanding, codebase includes the site svn, the > >> > > primary > git > >> > > repository, and all contrib repositories. Adoption of a new > >> > > codebase generally refers to the creation of a new contrib repository. > However, > >> I > >> > > could see it also expanded to cover things like re-doing the > >> > > entire > >> site > >> > > look and feel, or merging a contrib project into the primary > codebase. > >> > > Christopher, do you have any proposed verbiage that you would > >> > > like > to > >> see > >> > > specifically? > >> > > > >> > > 4) I very much disagree, Christopher. Having a dedicated > >> > > release > >> manager > >> > is > >> > > critical to having a release occur in a timely manner. Further, > >> > > the community needs to be able to make hard decisions, like > >> > > setting a > >> feature > >> > > or code freeze date, or pulling incomplete work out of a branch. > Right > >> > now, > >> > > we have release managers in name only, and I would love to see > >> > > us > give > >> > them > >> > > more authority on performing the release - right now we have a > steady > >> > > stream of small changes that developers feel should be exempt > >> > > from > the > >> > > freeze, something I'm guilty of myself as well. I see the lack > >> > > of a formalized release plan as one reason for why releases > >> > > tend to drag > on > >> > for > >> > > far too long. > >> > > > >> > > In short, if we don't have a release manager pushing for them, > >> > > then releases just won't happen. It's a gruelling task, and we > >> > > need to > have > >> > > procedure to bless somebody to do it. > >> > > > >> > > > >> > > Mike > >> > > > >> > > > >> > > On Mon, Mar 10, 2014 at 11:03 PM, Bill Havanki < > >> > [email protected] > >> > > >wrote: > >> > > > >> > > > My sense from the conversations leading up to the vote: > >> > > > > >> > > > 1) I believe the list is comprehensive, in that no other > >> > > > voting > >> actions > >> > > are > >> > > > contemplated. If we realize we need a new one, we can add it > later. > >> > > > > >> > > > 2) We determined that a committer, by ASF rules, cannot truly > >> > > > lose committer status [1], so no removal procedure is > >> > > > defined. Removal > of > >> a > >> > > PMC > >> > > > member is up to the ASF Board [2], so no procedure is defined. > >> > > > > >> > > > 3) I see no harm in adding a definition. > >> > > > > >> > > > 4) I think the "release plan" is the process for cutting a > release, > >> > while > >> > > > "product release" is for approving a specific RC as the release. > For > >> > me, > >> > > a > >> > > > boilerplate release plan with customizations (who is the RM, > >> > > > what > >> tests > >> > > are > >> > > > needed, time frame for freezes, etc.) would be nice to have > >> > > > laid > out. > >> > > > > >> > > > [1] > >> > > > http://www.apache.org/dev/committers.html#committer-set-term > >> > > > [2] http://www.apache.org/dev/pmc.html#pmc-removal > >> > > > > >> > > > > >> > > > On Mon, Mar 10, 2014 at 5:52 PM, Christopher > >> > > > <[email protected] > > > >> > > wrote: > >> > > > > >> > > > > Since I didn't technically vote, I guess I will now: > >> > > > > I'm going to give it a -1, pending the resolution the > >> > > > > following issues, and for an opportunity to correct the > >> > > > > minor > >> > punctuation/typos. > >> > > > > > >> > > > > Specifically, I'd like these addressed before I change my vote: > >> > > > > 1) clarification of whether the ACTIONS list is > >> > > > > comprehensive > >> > > > > 2) clarify reinstatement in the absence of a lack of > >> > > > > removal > >> > procedures > >> > > > > 3) codebase defined (or at least, Adoption of New Codebase > >> clarified) > >> > > > > 4) remove "release plan" as requiring a vote (or discuss), > because > >> > > > > while it is nice to coordinate release candidates through a > release > >> > > > > manager, I'm not sure it should be strictly necessary that > release > >> > > > > candidates be planned, or limited to that release manager. > >> > > > > > >> > > > > > >> > > > > -- > >> > > > > Christopher L Tubbs II > >> > > > > http://gravatar.com/ctubbsii > >> > > > > > >> > > > > > >> > > > > On Mon, Mar 10, 2014 at 5:08 PM, Christopher < > [email protected]> > >> > > > wrote: > >> > > > > > ***Punctuation: > >> > > > > > > >> > > > > > PMC section: > >> > > > > > "PMC from a Foundation perspective is" -> "PMC, from a > Foundation > >> > > > > > perspective, is" > >> > > > > > "Secondly " -> "Secondly, " > >> > > > > > "long term" -> "long-term" > >> > > > > > "not coding - but to ensure" -> "not coding, but to ensure" > >> > > > > > "Within the ASF we worry" -> "Within the ASF, we worry" > >> > > > > > > >> > > > > > VETOES section (comma): > >> > > > > > "veto - merely that" -> "veto, merely that" > >> > > > > > > >> > > > > > ***Typos: > >> > > > > > > >> > > > > > APPROVALS section (typo): > >> > > > > > "that -1 votes" -> "than -1 votes" > >> > > > > > > >> > > > > > ***Definitions: > >> > > > > > I would like to see "codebase" defined. It's used > >> > > > > > throughout, > but > >> > is > >> > > > > > never clearly defined... particularly in the "Adoption of > >> > > > > > New Codebase" section of the ACTIONS section. > >> > > > > > > >> > > > > > ***Other: > >> > > > > > In the ACTIONS section, it describes reinstatement > >> > > > > > actions, > but > >> not > >> > > > > > removal actions, so it's not clear what reinstatement means. > >> > > > > > > >> > > > > > It should also be made clear that the ACTIONS section is > >> > > > > > not a comprehensive list of actions. > >> > > > > > > >> > > > > > I'm also not sure that the "Release plan" should require > >> > > > > > a > vote, > >> as > >> > > > > > this seems covered by the "Product release" situation. > >> > > > > > The > other > >> > > > > > actions seem to imply a vote is required for that action. > >> > > > > > Are > we > >> > > > > > saying that planning to release requires a vote? If so, I > >> > > > > > can > get > >> > on > >> > > > > > board... I just don't remember that happening in the > >> > > > > > past, so > >> this > >> > > > > > isn't so much a formalization of our existing practices, > >> > > > > > but > also > >> > > > > > establishing a new one as well. And, in this case, I'm > >> > > > > > not > sure > >> > it's > >> > > > > > one we need. > >> > > > > > > >> > > > > > -- > >> > > > > > Christopher L Tubbs II > >> > > > > > http://gravatar.com/ctubbsii > >> > > > > > > >> > > > >> > > >> >
