Hi Thomas, Thank you, it's clear. My 2 cents is that, as long as you consider 1.4 not ready for production (beta), any fix shall be made on both versions. I know it is a double work, but it could be even simpler in term of versioning (same extra number at the end, for instance 1.3.180 and 1.4.180), such that both versions contains the same code, except the MVC. And if both versions are not so far from each other, it should not be that difficult. What do you think ?
Regards, Frederic Le jeudi 8 mai 2014 18:59:43 UTC+2, Thomas Mueller a écrit : > > Hi, > > > Will be there other 1.3.X versions or now it is only 1.4.X versions ? > > It's too early to say. If important bugs for the 1.3 are found, and demand > for 1.3 is high, then a new 1.3.x version will be released. > > > Does this mean that reverting back to "old" way (not MVStore) is not > supported/not recommended in production from 1.4.177 ? > > With "revert to non-MVStore for testing" I mean: if you find a problem > with 1.4, and you are not sure if this is caused by the MVStore, then you > could disable the MVStore, to find out whether this is really the case. > > The 1.4.x branch is still "beta", so I wouldn't use it for production. Of > course 1.4.x can, and should be used for testing. Sometime in the future, > the non-MVStore mode will be removed, but it's not clear when this will be. > > Regards, > Thomas > > > > > > > > On Wed, May 7, 2014 at 9:15 AM, Frederic Brégier wrote: > >> Hi, >> Might be silly questions (already asked or answer already written >> somewhere): >> >> - Will be there other 1.3.X versions or now it is only 1.4.X versions ? >> - According to website, the way to deacivate MVStore in 1.4, thus failing >> back to 1.3 way but with the last correction included is done "by >> appending ";MV_STORE=FALSE" and/or ";MVCC=FALSE" to the database URL". But >> in the very same sentence, the words "For testing" are written. Does >> this mean that reverting back to "old" way (not MVStore) is not >> supported/not recommended in production from 1.4.177 ? >> >> Cheers, >> Frederic >> >> Le mardi 6 mai 2014 07:44:01 UTC+2, Thomas Mueller a écrit : >> >>> Hi, >>> >>> Is there a documented numbering strategy, somewhere? >>>> >>> >>> Yes, higher numbers are better :-) >>> >>> Maybe H2 should not be at version 2.x or 3.x according to "Semver". But >>> for normal users, there are actually no API changes. The JDBC API is still >>> the same, and SQL didn't change either. The biggest change is the file >>> format change, which means you can't easily go back to an old version, but >>> as far as I see this only requires a minor version change in "Semver". >>> >>> In any case, you probably wouldn't reach numbers as high as 176 with >>>> this numbering scheme. >>>> >>> >>> This is the build number for H2. It is used in error messages as well. >>> >>> Regards, >>> Thomas >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "H2 Database" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/h2-database. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/d/optout.
