Menu
▾
▴
Re: [GUSDEV] managing GUS releases
|
From: Steve F. <sfi...@pc...> - 2005-07-08 20:17:15
|
all- i think fernan layed out a lot of good issues, and i think mike very accurately offered what we have in mind. the brief version is: - we branch when we make a release, eg, 3.7 - as bugs come up in 3.7, we modify that branch, and merge into the trunk as needed. - when the release master determines that the bug fixes need to be released (a balance between their urgency and his/her time), he or she tags the branch with 3.7.1, and does the release to the download site. (if we're clever we'll augment the build system's release facility to take care of all of this with a button push). - users of gus get their version of gus exclusively from the download site. - we separate the GUS schema and the GUS App. Framework into their own projects and release them on their own independent schedule, but the download site instructs the user as to their compatibility. steve Michael Saffitz wrote: >Hi Fernan, > >Comments below. > >On 7/7/05 10:35 AM, "Fernan Aguero" <fe...@ii...> wrote: > > > >>+----[ Steve Fischer <sfi...@pc...> (06.Jul.2005 20:29): >>| >>| Fernan- >>| >>| see below for response to your first point. >>| >>| for your second point, i strongly urge you to cut and paste into a new >>| posting to the group with an appropriate subject. its too important a >>| topic to be buried inside this one. >> >>OK, will do. >> >>| steve >>| >>| Fernan Aguero wrote: >>| >>| >Steve, >>| > >>| >here are my ideas about the part of your proposal that deal >>| >with 'managing branches'. >>| > >>| >I agree with you on the branching before release, therefore >>| >freeing the main trunk for continuing development towards >>| >future versions. I also agree on the 'tagging' of already >>| >released branches to provide landmarks of bug fixing >>| >activity. However I think that it should also be pointed out >>| >that usually you don't need to wait for the release engineer >>| >to post a new tarball ... in your example, people can just >>| >track the '3.6' branch and get all bug fixes irrespective of >>| >the minor version. Am i correct? >> >>| i am not sure i understand what you mean by tracking the 3.6 branch. >>| perhaps you mean downloading from the repository directly using the >>| tag? the one thing we don't want is for people to download and use >>| untagged versions. then we don't know what they have, and can't >>| properly track bugs, etc >>| >>+----] >> >>It's my personal bias towards a source centric view of the world :) >>And it's also part of my FreeBSD heritage, where 'tracking' is >>intimately related to the use of cvsup to sync sources >>against a cvs repository. >>http://www.polstra.com/projects/freeware/CVSup/ >>http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvsup.html >>http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/synching.html >> >>The thing I was trying to say is that once you do a major >>release, the branch (3.6 in this example) does not undergo >>further development. So if this is set as a policy (in >>FreeBSD old releases are owned by a security officer and >>normal people with commit privileges (committers) cannot >>under any circumstances make changes to these branches) then >>anyone 'checking out' the 3.6 branch using cvs (not the >>tagged release, because there maybe bug fixes since the >>release) or 'tracking' the 3.6 branch using cvsup (if you >>find it useful to have a cvsupd server installed) is sure to >>have the latest and most up to date version in the 3.6 line. >> >> >> > >As a matter of policy, it's my understanding that we all agree that a >particular release branch will not have any further feature development-- >only bug fixes. But I should also point out that non-urgent bugs could also >be provided in the trunk for the next release and never released as part of >a patch to the current release. > > > >>You might as well tag the repository for each bug that is >>fixed, but this assumes that there will be little activity >>... so you will have 3.6p1 (patch 1), 3.6p2, and so on. If >>the activity is higher, then tagging that much maybe >>overkill. >> >> > >Yes--- I think that's overkill. After all, with subversion (which we're >using) each checkin is numerically tagged anyway. > > > >>The thing here is making the load lighter on the >>release engineer ... just do the hard work (getting tarballs >>out the door) for major releases. Users get minor releases >>and bug fixes by applying patches or updating their sources >>from the repository. What if you release 3.6.1 and >>then notice that you missed a critical file or bug fix? You >>need to do another release, 3.6.2. This is not necessary if >>users checkout/track the repository. Does this sound >>reasonable? >> >> > >The issue is that user's won't have a working copy to update-- their >original should be from the distributable. I think downloading the updated >distributable is a trivial task, but I do agree that we could do more to >make it even easier (I'm thinking specifically here about if a file is >deleted as part of the release-- simply rerunning build GUS install -append >won't remove that file in the gus_home which could cause issues). > > > >>As to the issue of users working with 'untagged' versions, >>this is just a matter of educating users. And keep reminding >>people on the mailing list that they should do a cvs update >>(or cvsup) and check their problem against the most current >>version on any branch. >> >> >> > >No. The most current version will frequently be the trunk, which may not be >stable. If people find an issue in their release, they should: > >1) Check the bug tracker to see if the issue is known and/or resolved. > * If unknown, file a bug > * If known, and fixed, and released: upgrade if possible > * If known, and fixed, and unreleased: if urgent, apply patch > * If known and not fixed: submit patch or wait > > > > >>Again, the idea is that the changes that go into these >>'maintainance' branches should be easily applied to >>production sites. They should not break anything, so there >>shouldn't be a problem updating a gus installtion against >>the most recent version in the same branch. >> >>It's just a suggestion. I would always prefer to track the >>3.6 branch instead of downloading separate 3.6.1, 3.6.2, >>etc. versions. And of course this doesn't preclude that you >>might do minor releases where appropriate. >> >> > >And that's ok for people comfortable with it, but I think for most people, >the new "traditional" release/distributable paradigm will provide a better >experience. > >These, of course, are just my opinions/suggests... We should make sure the >community is comfortable with whatever the "recommended" approach is. > > > >>Fernan >> >> >>------------------------------------------------------- >>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies >>from IBM. Find simple to follow Roadmaps, straightforward articles, >>informative Webcasts and more! Get everything you need to get up to >>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click >>_______________________________________________ >>Gusdev-gusdev mailing list >>Gus...@li... >>https://lists.sourceforge.net/lists/listinfo/gusdev-gusdev >> >> > > > |
