IMO we will not be able to sync OEJB releases versions the specs versions, because for sure we want and we do add new features to satisfy the needs of better EJB development using OEJB for our users. So documentation and release notices play a big role in that matter as it is the way users will know which EJB version(s) we support, this is beside the publicity that David talked about through whatever entity - InfoQ or TSS or both or someone else. I mean, lets follow the conventional versioning scheme, which is 3.x for new additions and features and 3.0.x for bug fixes, cause this is the expected scheme by most users, and we should not care - and we will not be able to follow the specs versions. But for this specific situation and for the sake of OEJB publicity , I vote for 3.1 release version as it will sound better in the ears of users and InfoQ and/or TSS readers as it is so related to the EJB 3.1 specs, but later we can follow our own release versioning as normal.
On Sun, Jun 29, 2008 at 3:30 PM, Kevan Miller <[EMAIL PROTECTED]> wrote: > > 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 > > > > > > > > -- Thanks - Mohammad Nour
