I agree with David. IMHO tt seems the best way to go. Having to support 2 or 3 releases seems reasonable. More seems infeasible in our actual reality.
I don't know much about it but it looks like how Debian is driven and that way seems to work well. If on the road we are lucky and find more ressources (I mean human ressources ;o) we may then go the way Ubuntu is going : creating a new release every 6 months (Debian frequency is 18 months if I'm not wrong). Also Ubuntu has chosen to support versions during 18 months. Ubuntu 6.06 LTS being the 1st exception : LTS stands for Long Time Support meaning 3 years for desktop 5 years for server here (BTW 6.06 means june 2006). I think we may inspire ourself by this support policy (inspiring is not copying ;o) and external releases numbering. We may have other release number in intern but that may complicate things a bit. In conclusion : I like this way to go because it's not too techie and simple to understand for end users (meaning not developpers here) WDYT ? Jacques ----- Original Message ----- From: "David E Jones" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Thursday, December 28, 2006 9:15 PM Subject: Re: Community supported releases WAS [Re: Properly edited OFBiz manuals] > > On Dec 28, 2006, at 2:09 AM, Jacopo Cappellato wrote: > > > David E Jones wrote: > >> I guess it depends on what the goal of doing a release is. In my > >> mind the goal should be to create (over time...) a stable set of > >> artifacts that people can build and deploy on if they choose not > >> to go with the latest/greatest. > >> What you're describing is interesting, but how is that any > >> different than just using the latest from SVN with a little timing > >> based on knowing what is going on added in, and keeping a list > >> somewhere of all non-backwards compatible changes and their > >> revision numbers? > > > > Yes, you have described pretty well what I'm suggesting; I'd only > > add to these that we should also create the upgrade services (and/ > > or upgrade instructions) every time we commit a non-backwards > > compatible change in svn. As you said, this is not so different > > from what we are (implicitly) suggesting to do right now (as a best > > practice to stay up-to-date with the trunk) but I think that it > > would be nice if the community will officially support it for a few > > reasons: > > > > 1) it's often difficult for users to pick a 'stable' svn snapshot > > 2) it's often difficult for users to keep track of important > > changes between their revision and the trunk > > 3) since it is not so different from what we are suggesting right > > now, it will not add a huge cost maintaining these extra processes/ > > releases > > The problem I see, trying to look at it from the point of a > prospective end-user, is that this sort of frequent release doesn't > help me a lot. > > 1. If I want a good, stable version where I don't have to worry about > bugs, which one do I choose? > > 2. If I realize there is no perfect version because of constrained > community resources but at least want to group together with others > to support a certain release, which one do I choose when there are so > many coming out so fast? > > 3. Once I have chosen and have been running for a while and want to > upgrade OFBiz, which newer version do I choose (related to the above > questions) and how much work is it going to be to not be able to > update from that version to the version I choose, but instead go > through the upgrade processes for every version between that one and > the one I choose? > > > >> But, back to the main point: what is the goal of a release in your > >> mind (and in the mind of anyone else reading in too)? > > > > I'd like to get the opinions from others too. > > Personally I think that releases (or release instructions/plans) > > should at least help users to keep their system/data in sync with > > the main trunk, minimizing the upgrade costs and simplifying the > > users' decisions (i.e. "should I upgrade now?"). > > Of course it would also be great to have a real 'stable' releases > > (with patches for them etc...) as you are suggesting (and I really > > think we could implement the two approaches simultaneously since > > what I've proposed could be the basis of a real release management) > > but I'm not sure the community will really maintain them... > > I'd say if people want to stay in sync with the trunk, there is > nothing better than the trunk for doing so... In my opinion doing > some sort of regular "release" would only make it more difficult for > people to keep up with the trunk and participate in or contribute to > OFBiz because they would never be quite up to date. > > What I'm hoping for is a single, infrequent branch that people can > rally around and maintain together. If we only do one of these each > year or so then there will never be a question about which one needs > fixes back patched to it as we'd only support at MOST 2-3 of these at > any given time. That would mean people would need to update at least > once every 3 years, but of course that's just a random artificial > number and being a community driven thing if there is a group that > wants to continue to maintain an older branch then great, more power > to them! > > People looking for a good release to use if they are asking question > #1 above would use the latest release in the latest stable branch > that is at least, say, 3 months old. For people asking question #2 > above they could just use the latest stable branch as-is from the SVN > directory for that branch and participate in making the branch better. > > -David
