One possibility, but not the encouraged solution - hopefully the need
for a patch would drive customers to buy the product. This approach
also fixes a few nightmarish logistical problems regarding handling
promoting fixes from product to project AND vice-versa. Add to that
problem the product code base probably won't 100% match the project
code base to begin with, and your brain really begins to hurt.
On Apr 23, 2009, at 10:38 AM, Larry O'Leary wrote:
I see. Makes complete sense. If I need a patch/fix for a release
of
the project then I would be responsible for building it myself.
On Thu, 2009-04-23 at 10:30 -0500, John Verhaeg wrote:
> What I'm really trying to address with the release version issue is
> the official direction that RedHat/JBoss have stated they want to go.
> No matter what we call it, be it an "update release" or "patch",
the
> direction is to not offer either of these in the project side of the
> world. If something is broken in one release, the earliest time to
> see its fix will be the next minor release. I believe the rationale
> for this is partly to further the idea that if you really need patch-
> level support, buy the product.
>
> On Apr 23, 2009, at 10:27 AM, Larry O'Leary wrote:
>
>> ...
>> As for patch releases, your are correct, they shouldn't really be
>> done
>> but we shouldn't confuse a patch with a revision release. A 6.0.1
>> release would give us an opportunity to role critical usability and
>> execution bug fixes into an already released 6.0. We would think of
>> this as an update release and not a patch.