On Jun 28, 2008, at 1:21 PM, Jacek Laskowski wrote:
On Sat, Jun 28, 2008 at 12:11 PM, Manu George
<[EMAIL PROTECTED]> wrote:
Hmm I see your point David. So I guess it makes sense to go with 3.1.
So what do we plan to call future releases delivering EJB 3.1
support?
3.x or 4.0?
3.1.1, 3.1.2 and so forth.
Heh. But InfoQ (or whoever) might not be interested in a 3.1.2
release... Which is Manu's point, I think... Or at least it would be
my point... ;-)
Basing decisions on headline grabbing potential seems like a poor
starting point for making this decision, IMO. Heck, if 3.1 will get a
notice, wouldn't a 4.0 release get a bigger headline? :-P I'll also
note that TSS just ran an article for a 1.3.4 release of Wicket.
IMO, the project has one fundamental decision: Do you want to base
release numbers on the supported EJB spec level? The ability of the
project to introduce new "features" is going to far outpace the
ability of the JCP to generate new EJB spec version numbers. By
convention, 3.0.1 would be a bug-fix update of the 3.0 release. New
"features" do find their way into bug-fix releases, but you'd usually
expect most new features to appear in 3.x releases. However, that
doesn't mean you absolutely *must* follow the convention... Allowing
3.0.x releases to introduce new features. It's then a matter of
communicating the content. On the other hand, a 3.x release clearly
communicates new function.
I'm ok with either direction. A few additional thoughts...
Would be nice to discuss what users might want... Discussing releases
a bit further in advance would give committers a chance to target new
capabilities for them, etc...
--kevan
