Gah; for the other languages section, the only things to take care of are: - merge selected bugfixes from trunk/ to branch-1.3/ - as the merge is committed, set "fix-for" to be 1.3.3 in jira - update CHANGES.txt in both trunk/ and branch-1.3/
On Mon, May 24, 2010 at 1:32 PM, Jeff Hammerbacher <[email protected]>wrote: > Yep, sounds reasonable. I took care of: > > > - add a 1.3.3 target in Jira > - add to CHANGES.txt a 1.3.3 section in both trunk/ and branch-1.3/ > > For the various languages, could others take care of: > > > - add a 1.3.3 target in Jira > - add to CHANGES.txt a 1.3.3 section in both trunk/ and branch-1.3/ > - merge selected bugfixes from trunk/ to branch-1.3/ > - as the merge is committed, set "fix-for" to be 1.3.3 in jira > - update CHANGES.txt in both trunk/ and branch-1.3/ > > Once you've taken care of the above for your language, make note of it on > this thread. Once I've heard from everyone, we'll proceed with a release > candidate. > > Thanks, > Jeff > > > On Mon, May 24, 2010 at 11:16 AM, Doug Cutting <[email protected]> wrote: > >> On 05/24/2010 05:20 AM, Bruce Mitchener wrote: >> >>> To be clear, this would need to be a branch from 1.3.2 ... the stuff on >>> HEAD >>> for Avro C is 1.4 material (in-progress breaking API changes). >>> >> >> There's already a 1.3 branch in subversion. All bugfixes should generally >> be first committed to trunk. The process should be roughly: >> >> - add a 1.3.3 target in Jira >> - add to CHANGES.txt a 1.3.3 section in both trunk/ and branch-1.3/ >> - merge selected bugfixes from trunk/ to branch-1.3/ >> - as the merge is committed, set "fix-for" to be 1.3.3 in jira >> - update CHANGES.txt in both trunk/ and branch-1.3/ >> >> Once we're happy with the set of bugfixes in 1.3.3 then someone can tag it >> with a candidate tag, roll a release candidate, and call a vote. >> >> Does that sound reasonble? >> >> Doug >> > >
