Hi all, I don't know if my opinion is really important, but I think it's time to release something (some fixes are very important and the list is full).
Regarding 3.0.1 vs 3.1, +1 for 3.1 ! Jean-Louis mnour wrote: > > 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 > > -- View this message in context: http://www.nabble.com/Getting-near-release-time-tp18080713p19254861.html Sent from the OpenEJB Dev mailing list archive at Nabble.com.
