That doc says this: "Release branches will be created approximately once per year; these will
represent a new minor version number, and in cases of major and/or non-backward compatible changes
a major version number".
Does that mean a major release once a year (I'm hoping)? I did project that OFBiz 5.0 will be out
around mid-2008. Did I just shoot myself in foot? :P
Is it possible to do a quarterly minor version release, so we might have up to 4.4 before we roll
out 5.0? Actually, 4.x can go up to 4.11 or more if it's really popular, and many folks just can't
tear themselves away from 4.x family to jump to 5.0 (which will require a migration effort from
4.x). Release 4.x and 5.x won't need to be backward-compatible.
Of course, it all depends on how widely used and tested and developed 4.x branch is. If all we
roll out is a single new feature to hide typed passwords, it'll be pretty embarrassing to roll out
4.1 and pretend like it's some significant quarterly update.
I'll try to push the release branch more in near future, next few months. More tests, more
complaints, more fixes, etc.
Jonathon
David E Jones wrote:
Shoot, forgot the link:
http://docs.ofbiz.org/display/OFBADMIN/Release+Plan
-David
On Nov 15, 2007, at 12:21 AM, David E Jones wrote:
Here is the current release plan that explains everything related to
this. It is certainly open to change.
The best way to do that is probably to propose variations on the
current plan and open discussion on them.
Will be interesting however the conversation goes... (as Dan Shields
mentioned, with some liberty in variation)
-David
On Nov 14, 2007, at 9:22 PM, Jonathon -- Improov wrote:
Ok, I'm just speaking from a business perspective here. Obviously,
from developer's perspective, it's good to put that enchancement into
release 4.0. I agree that this is not a fix, but an enhancement.
First, it's cool to be able to tell clients that a new release (after
4.0) fixes a problem with clear passwords being shown. So, I'm for
rolling that enhancement into the next release (say 4.1?). Oh yeah,
we do agree that upgrading along the 4.x family should involve zero
migration effort, right?
That said, it should be obvious that my hope is to have release 4.0
stabilized asap, and free up resources to package and roll out the
next release. If we're not gonna be fast and rapid about the release
timeframe, then getting stuck with 4.0 for a long time (say a year?)
and stuck with this problem is not fun.
Next, I also agree that we cannot dilute the meaning of "bug", and
start throwing in seemingly harmless and super-stable enhancements
into the release branches. Take no chances. I do agree that this
particular enhancement should be simple and superficial enough to be
harmless. But for the sake of audit and organization and management,
bug fix and enhancement should be handled as clearly distinct
categories.
Finally, I'd like to suggest a little trick we often do with such
deal-breaker "bugs" (ie, "bugs" for which we say "it's a feature!").
Releases like 4.x (where x > 1) can include such enhancements. Sort
of like "hotfixes" for release branch 4.
Will that mean maintaining 2 branches (4.0 and 4.1), and having to
apply any new patches to all members of the 4.x family? Yes! But...
it's not difficult. We need to make sure that all members of the 4.x
family are fully compatible with each other, ie enhancements being
thrown in are truly harmless and superficial enough that each 4.x
member is very largely similar (not fundamentally overhauled). In
short, all enhancements thrown into the 4.x family must *not* make it
less than super-easy to apply bug fixes uniformly to all members. A
bug fix to 4.x must be applicable to 4.y without any transformation.
Hope that helps?
I'd also like to bring in some marketing and sales perspectives. When
we market our clients' products, we need to create buzz or activity.
Having very regular and frequent releases along the 4.x family makes
it tangibly known that OFBiz is super-active and is improving at
breakneck speed.
Jonathon
David E Jones wrote:
I'd prefer not to dilute the meaning of "bug". A bug is an existing
feature that doesn't work as it was intended when written.
Passwords in plain text would be a security issue, but since the fix
for that issue is most likely a new feature rather than fixing an
existing feature (I haven't looked at the code so I don't know if
there is broken code that should do this, but it doesn't sound like
it), then it is a new feature and not a bug.
So, the question that started this thread is the most relevant:
because it is a big concern, should we add this to the branch even
though it is a new feature and not a bug fix?
My opinion on that is let the users of the branch decide... I'm not
really in a good position to express an opinion because I make a
regular practice of pushing clients away from the branch and to the
trunk so that new work we do for them (new stuff being most of what
we do as a company) can be done in participation with the project.
We could do a formal vote where only PMC votes are binding, but it
might be more valuable to just get feedback from branch users and
make a decision. Purely an administrative comment that.
-David
On Nov 14, 2007, at 11:22 AM, Michael Jensen wrote:
I agree with Tim. It's a security related bug fix. Displaying
passwords in plaintext on a screen is a bug. It is industry standard
practice to not show passwords on the screen (either by replacing
w/asterisks or not displaying characters at all.)
Mike
Adrian Crum wrote:
Tim,
From my perspective, it would be like finding a security breach in
the
branch. Would we want to close the security breach? Of course! Are we
adding a new feature by doing so? I guess some people would
consider a
closed security breach a "new feature" - but the people
downloading and
deploying the branch would consider it a bug fix.
-Adrian
Tim Ruppert wrote:
I'm only against breaking the rules of the branch for this one
feature enhancement. If the application doesn't work, then it's a
fix though. So, I guess it goes back to whether or not this is
a fix
of a problem that was there or is it a feature enhancement?
Cheers,
Tim
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com
o:801.649.6594
f:801.649.6595
On Nov 14, 2007, at 10:59 AM, Scott Gray wrote:
I'm not agiainst it, +1
Scott
On 15/11/2007, Vince M. Clark <[EMAIL PROTECTED]> wrote:
+1
Vince Clark
Global Era
The Freedom of Open Source
[EMAIL PROTECTED]
(303) 493-6723
----- Original Message -----
From: "Adrian Crum" <[EMAIL PROTECTED]>
To: dev@ofbiz.apache.org
Sent: Wednesday, November 14, 2007 10:16:31 AM (GMT-0700) America/
Denver
Subject: Re: release4.0: OFBIZ-1106 (in or out?)
While technically it is not a bug fix, I believe it should go in
anyway - since the release is
intended to be widely deployed, and the problem your patch
addresses might be a deal breaker for
those who are considering deploying the release.
+1 for including it.
-Adrian
Dan Shields wrote:
Thanks Jacques for helping get my patch for OFBIZ-1106 into
OFBiz.
Hello Devs, recently I participated with other developers to
devise a
fix for OFBIZ-1106. The patch I submitted is now in HEAD but
UNsurprisingly it has been held back from release4.0 because the
acceptance criteria, I am told, accepts only bug fixes.
Some would agree that release4.0 was unusable for POS for the
fact
that it echos the manager's and the user's password to the
screen for
all staff and customers to see. I don't know if any other
developer
has tried to train non-computer people to use the POS
application,
but
I have seen the genuine surprise on their faces when they saw
their
own password appear on the screen as they typed. It should be
self-evident that this is undesirable behavior. My patch merely
replaces the characters on the screen with asterisks; it does
so in a
manner that respects existing APIs employed by the OFBiz POS
application, it is well-tested, cleanly applies to HEAD and
release4.0, and has been tested by other ofbiz developers as
well.
It seems that there is some uncertainty over whether this is in
fact a
bug fix or not. I am merely asking for additional support in
deciding:
"For the purposes of release4.0, is my patch for OFBIZ-1106 a bug
fix?"
--
Millcreek Systems, Inc.
P.O. Box 9835
Salt Lake City, Utah 84109
Phone: 801.649.4903
Skype: millcreeksys (http://millcreeksys.com/skype/)
