OpenSocial Spec List, Any interest in changing the way we version future spec releases? On the Shindig dev list we are discussing what the next version of Shindig should be. We want to stay aligned with the spec version to alleviate confusion but also stay within the constraints of maven versioning rules. From the discussion so far it seems like other specs and implementations follow a versioning scheme where the spec only uses major.minor versions and implementations use major.minor.revision. This allows implementation to release updates and fixes while staying compliant with a certain version of a specification.
Sine we are so close to releasing 2.5.1 I propose we make this change post 2.5.1. For now Shindig will release updates to 2.5.0 using maven qualifiers, so the next release of 2.5.0 will be versioned 2.5.0-update1. In the future we would like to avoid using qualifiers for anything other than alpha/beta releases because it can effect version ranges in maven. Thoughts? -Ryan On Thu, Aug 8, 2013 at 9:17 PM, Matt Franklin <m.ben.frank...@gmail.com> wrote: > > >> On Aug 8, 2013, at 17:52, Ryan Baxter <rbaxte...@apache.org> wrote: >> >> Does anyone think it is work going to the OpenSocial list and asking >> if post 2.5.1 we stick to using only major.minor versioning? This >> allow Shindig to stick to use the revision field for updates that are >> not necessarily spec related. > > +1 > >> >>> On Wed, Aug 7, 2013 at 5:02 PM, Henry Saputra <henry.sapu...@gmail.com> >>> wrote: >>> The OpenSocial specs have major.minor.revision versioning scheme, so the >>> discussion is either we follow OpenSocial versioning up to the "revision" >>> or just major.minor. >>> >>> If we want to follow up to the "revision" part then we need to add >>> "-updateXXX" or "rXXX" tail in Apache Shindig versioning which I think a >>> bit ugly (see Hadoop release versions, ugh) >>> >>> - Henry >>> >>> >>> On Tue, Aug 6, 2013 at 10:30 PM, Marcel Offermans < >>> marcel.offerm...@luminis.nl> wrote: >>> >>>> Maybe it makes sense to use semantic versioning, as described here: >>>> http://semver.org/ >>>> >>>> If indeed the specs are major.minor then you can implement with >>>> major.minor.patch >>>> >>>> Greetings, Marcel >>>> >>>>> On Aug 7, 2013, at 7:14 AM, Craig McClanahan <craig...@gmail.com> wrote: >>>>> >>>>> FWIW an approach to version numbers I have seen a lot is that the >>>>> major.minor version numbers match the spec being implemented (2.5 in this >>>>> case), but anything after that is totally up to the implementation. So, >>>>> 2.5.1 ... 2.5.2 ... etc. would be fine for improved implementations of >>>> the >>>>> 2.5 spec. >>>>> >>>>> It's also perfectly reasonable to think about 2.5.1-rc1 and 2.5.1-rc2 >>>> (and >>>>> so on) for release candidates of 2.5.1 before a final 2.5.1 release. >>>>> >>>>> Craig >>>>> >>>>> >>>>>> On Tue, Aug 6, 2013 at 2:03 PM, Ryan Baxter <rbaxte...@gmail.com> wrote: >>>>>> >>>>>> Henry does JSF use revision numbers or do they stick to major and >>>>>> minor version only? If the revision numbers are not going to match >>>>>> anyways than maybe we shouldn't worry about calling the next Shindig >>>>>> release 2.5.1. >>>>>> >>>>>> On Mon, Aug 5, 2013 at 9:41 PM, Henry Saputra <henry.sapu...@gmail.com> >>>>>> wrote: >>>>>>> The next version of Shindig will contain the first release without PHP. >>>>>>> I believe that's worth a bump in revision part of the version to 2.5.1. >>>>>>> >>>>>>> @Ryan, I would love to keep it in-sync but Shindig will move faster >>>> than >>>>>>> spec development and it would be hard to keep up with the exact >>>> version. >>>>>>> I believe other projects like Apache Tomcat and Apache MyFaces (latest >>>>>>> release is 2.1.12 that implement JSF 2.1) that also implement open >>>> specs >>>>>>> follow its release version up to certain levels. >>>>>>> >>>>>>> I like @Matt's idea, we could release 2.5.1-alphaX releases but final >>>>>>> release should be 2.5.1 but branching early to add minor emergency >>>> fixes >>>>>>> with 2.5.0-update1. >>>>>>> >>>>>>> - Henry >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Aug 5, 2013 at 5:08 PM, Matt Franklin < >>>> m.ben.frank...@gmail.com >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>>> On Aug 5, 2013, at 20:03, Henry Saputra <henry.sapu...@gmail.com> >>>>>> wrote: >>>>>>>>> >>>>>>>>> I am actually still +1 for just 2.5.1. We agreed that Shindig version >>>>>>>> will >>>>>>>>> adhere to OpenSocial specs up to minor version which in this case is >>>>>>>> 2.5.x >>>>>>>> >>>>>>>> What about developing in trunk at 2.5.1-alphaX and branching for fixes >>>>>> in >>>>>>>> 2.5.0-update1? >>>>>>>> >>>>>>>> I also think 2.5.1 should be relatively minor in changes to the >>>>>> software >>>>>>>> itself. Ideally, only additions and no breaking changes to existing >>>>>>>> interfaces, etc. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> - Henry >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Mon, Aug 5, 2013 at 4:50 PM, Ryan Baxter <rbaxte...@gmail.com> >>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Here is what I found on version numbers [1]. From what I gather >>>>>> after >>>>>>>>>> reading that using 2.5.0.1 would be considered "non-standard". The >>>>>>>>>> only downside to this would be the version numbers would be compared >>>>>>>>>> as strings. We could use 2.5.0-fix1 which would be considered >>>>>>>>>> standard, but I don't think that buys us anything with regards to >>>>>>>>>> version comparison. I could pose a question to the Maven users list >>>>>>>>>> and see if they have any advice. >>>>>>>>>> >>>>>>>>>> [1] >>>> http://books.sonatype.com/mvnref-book/reference/pom-relationships-sect-pom-syntax.html >>>>>>>>>> >>>>>>>>>> On Mon, Aug 5, 2013 at 7:34 PM, Stanton Sievers < >>>> ssiev...@apache.org >>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>> +1. Shindig-1924 is one such cleanup. I also agree with staying in >>>>>> line >>>>>>>>>>> with the spec. >>>>>>>>>>> >>>>>>>>>>> I would just want to make sure we have no technical or process >>>>>> issues >>>>>>>>>> with >>>>>>>>>>> maven artifacts (or the like) with 4 numbers in the version. >>>>>>>>>>>> On Aug 5, 2013 7:29 PM, "Ryan Baxter" <rbaxte...@apache.org> >>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> The current version of trunk is set to 2.5.1. I am wondering what >>>>>>>>>>>> people think of changing that to 2.5.0.1? There are a few cleanup >>>>>>>>>>>> changes that have already been identified that would be good to >>>> get >>>>>>>>>>>> out there. At same time we want to stay in sync with the spec >>>>>> version >>>>>>>>>>>> so I don't think we want to release 2.5.1 yet. What does everyone >>>>>>>>>>>> think? >>>> >>>>
