This has been already discussed to and fro and I totally agree
Jacques
From: "David E Jones" <david.jo...@hotwaxmedia.com>
The Release Plan document does cover this:
http://docs.ofbiz.org/display/OFBADMIN/Release+Plan
The whole point of doing a release branch is so that we never have to do a feature freeze in the trunk. The release branch is the
place where we never allow new features, and in the trunk they are always allowed.
As for why to wait longer, I'm still thinking the end of March is a better
date since a few things are up in the air:
1. completing MyPortal: remove MyPage, move MyPortal to framework
2. framework independence: move all references to non-framework things (especially Party) from framework components into
applications components, and in general make the framework free of dependencies on the applications
There may be more things, but IMO those 2 items are critical to finish before the release branch so that the branch won't start
out with significant issues that require refactoring and not bug fixes, and so will never be done in the release branch. Those
who want such things would then have to wait another year or two for the next release branch, or use the trunk, which would make
this release branch of less value.
And no, we're not going to do release branches more often. A release branch is only valuable if there are enough people using to
help maintain it and fix bugs in it. Having lots of release branches undermines that, and that issue is already a big one as the
release4.0 branch shows with only about 2-3 bugs ever fixed in it that were not back-ported from the trunk.
-David
On Mar 1, 2009, at 12:04 AM, Bruno Busco wrote:
Hi,
I think from this moment we should consider to stop adding new
features in the trunk until we create the release branch.
What do you think?
It is hopeful that the 9.3 will be created soon. Lots of users are
waiting to sit on it (including me ;-).
IMO there is no reason to wait longer. If, from this moment on, we
will take care of committing bug fixes to the trunk in separate
commits from improvement it will quite easy to merge them to the
release branch.
From the JIRA release 9.3 roadmap:
https://issues.apache.org/jira/browse/OFBIZ/fixforversion/12313602
I see three issues needs to be closed before releasing.
Any update?
-Bruno
2009/2/23 Jacques Le Roux <jacques.le.r...@les7arts.com>:
Personally I'd like to see all security issues solved before a new release.
There also are some other things I have not in head just right now (Colors
and localisation for the calendar is one of them)
Anyway if we are sure we will be able to fix all security issues before
freezing this release (hey, I did not say 9.3 ;o) I think it
should be ok.
By this last sentence I mean we may create a branch in march 2009. But this
will not imply that the release will be numbered 9.3.
Remember Ubuntu 6.06 should have been 6.04 ...
Jacques
From: "Bruno Busco" <bruno.bu...@gmail.com>
Why postpone it?
Will we not be able to close this in february/march?
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=12310500&fixfor=12313602&resolution=-1&sorter/field=issuekey&sorter/order=DESC
-Bruno
2009/2/23 Jacques Le Roux <jacques.le.r...@les7arts.com>:
In Ubuntu world they use LTS concept (Long Time Support) which means 5
(yes
five!) years of guaranteed support on these specific versions (there are
already 2 of them : 6.06 and 8.04).
Of course OFBiz is not an OS and I think we will never support a release
5
years (how could we do with the lack of manpower we still have despite of
all wonderful efforts we have seen taking place since the beginning of
this
project).
So I guess we will simply have releases (or versions, like 9.3, but I
guess
we will postpone its release, hence the number will change) and the trunk
as
it's already done.
In one word a version will be
either
trunk.releaseNumber
either
versionNumber.releaseNumber (like 9.3.999999)
Note that the footer shows already this information if you run the ant
svninfo target after your build
If we are all ok with this description (David?) I could add this to
http://docs.ofbiz.org/display/OFBADMIN/Release+Plan
And I think we should at least update title in
http://docs.ofbiz.org/display/OFBIZ/OFBiz+4.X+and+5.0
HTH
Jacques
From: "BJ Freeman" <bjf...@free-man.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
interesting. so how do you denote a minor release or update?
Bruno Busco sent the following on 2/22/2009 3:35 AM:
Sorry,
I did not understand your real question.
We have decided to use a release numbering scheme similar to UBUNTU.
9.3 means March 2009
-Bruno
2009/2/22 BJ Freeman <bjf...@free-man.net>:
so why did ofbiz jump from 4.0 to 9.3?
Bruno Busco sent the following on 2/22/2009 2:59 AM:
Well,
the unresolved issues scheduled for 9.3 are:
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=12310500&fixfor=12313602&resolution=-1&sorter/field=issuekey&sorter/order=DESC
OFBIZ-2133 has a patch ready and is actually waiting for a review.
-Bruno
2009/2/22 BJ Freeman <bjf...@free-man.net>:
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=12310500&fixfor=12313602
it say release Branch 9.3
so no 5,6,7, or 8
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJoTsArP3NbaWWqE4RAnAJAJwL2QBJ5qohvu0DQGY1vKErTrZsQQCfYO3V
R5s/zYI6xl/TJWO7Q4oOAZg=
=Zgcv
-----END PGP SIGNATURE-----
