In my observation, projects with semver tend to be forced to bump major versions rather frequently. So something like CMake in 2.0 or C++11 in 3.0 is not a big deal, because it's not likely we have long standing 1.x anyway.
That said, I'm not particularly against any 1.0 plan and 0.10.0 would be nice if 1.0 is controversial. Speaking about versioning, semver mandates us a defined set of public API that is covered by it. As I don't think we can document every individual API, we need a set of rules that can decide what belongs to public API. For example, Protocol.readFieldEnd, is it public API ? On Tue, Jan 12, 2016 at 8:08 AM Jens Geyer <jensge...@hotmail.com> wrote: > Hi *, > > > In this regard, 1.0.0 might be nicer because automatic pull is overtly > > inappropriate for this release IMO, at least for python and node. > > But that's what I'm saying: There will NEVER be a right time. You will hear > that same sentence next time, only with slightly different content. > > Have fun, > JensG > > PS: Thanks for all the work done in the last weeks, Aki. Highly > appreciated! > > > > -----Ursprüngliche Nachricht----- > From: Aki Sukegawa > Sent: Monday, January 11, 2016 3:17 AM > To: dev@thrift.apache.org > Subject: Re: Thoughts on a 0.9.4 rc > > conventional_changelog seems to have a lot of over-wrap with current JIRA > based one. > What is pros and cons of this ? Obvious ones are: > pros: > * lightweight > cons: > * handling typo, wrong/forgotten tags etc is tricky > > The version number might not matter that much to poeple but maybe it does > more to tools. > npm et al. are more likely to be configured to automatically pull > patch/minor version bumps. > In this regard, 1.0.0 might be nicer because automatic pull is overtly > inappropriate for this release IMO, at least for python and node. > > On Sun, Jan 10, 2016 at 7:43 PM Roger Meier <ro...@bufferoverflow.ch> > wrote: > > > Hi > > > > fully agree on more frequent releases and I personally do not care > > that much about the numbers. The cross testing is much more important. > > > > 0.10.0 why not or 0.9.4 if it is easier or a 1.0.0 it does not matter. > > > > The difficult thing is how do people really know what's changed and > > that's why I like to bring in the conventional changelog discussion > again. > > Latest *git log --pretty=full* would look like this example: > > > > --- > > fix(javascript): Dots in file names of includes causes dots in variable > > names > > Author: Kapil Joshi > > Commit: Jens Geyer <je...@apache.org> > > > > based on the equivalent C# version > > > > This closes THRIFT-3314 > > --- > > feat(python): Add package_prefix to python generator > > Author: Eric Klaus <eric.kl...@workiva.com> > > Commit: Jens Geyer <je...@apache.org> > > > > This closes THRIFT-3499 > > This closes #755 > > --- > > fix(dart): TSocket onError stream should be typed as Object > > Author: Mark Erickson <mark.erick...@workiva.com> > > Commit: Jens Geyer <je...@apache.org> > > > > This closes THRIFT-3520 > > This closes #770 > > --- > > feat(php): Add PHP 7 version of php_thrift_protocol > > Author: David Soria Parra <d...@php.net> > > Commit: Roger Meier <ro...@apache.org> > > > > This is an initial port of php_thrift_protocol to PHP7. However as > > we deal with zval's all over the place, we opt for separating > > the C files completely leading to some overhead. However this > > is a good start to see the differences in the implementation. From > > there we should follow up with a more unified approach by refactoring > > parts of the zval handling to be more generic so we can plug it > > into PHP 7 and PHP 5 extensions. > > > > Tested this by running with TestClient.php against a CPP server > > and using TBinaryProtocolAccelerated. > > > > This closes THRIFT-3514 > > This closes #765 > > --- > > > > See [1] for a nice introduction on conventional changelog and a > > generated CHANGELOG.md based on git commit data only. > > > > Cheers > > roger > > > > > > [1] > > > > > http://notebook.aaronwest.net/2015/08/03/better-documentation-using-conventional-changelog.html > > > > > > Quoting Jens Geyer <jensge...@hotmail.com>: > > > > > Hi, > > > > > > In general, I'm a proponent of more frequent releases. We had some > > > mails last year and the consensus that I remember was to have > > > something around 3 or 4 releases per year would be the optimum > > > (correct me if I'm wrong). > > > > > > How we number them ... well, as a matter of fact, Thrift is already > > > widely used in production. The languages on the market and their > > > capabilities are constantly changing and will continue to do so, and > > > so is Thrift, because of it's very nature of being a > > > connectivity-enabling framework. So more than with most other > > > software, there will never be /the/ one, 100% complete and 100% > > > final Thrift version, because things change and Thrift needs to be > > > constantly adapted. > > > > > > Version numbers around 1.0 are more a kind of a psychological thing: > > > Below 1.0, the project devs have more freedom with what they do, > > > because "the product is not final". So you kinda fly under the > > > radar. This changes with >= 1.0 and after. People are now looking > > > more closely, but they also take the whole thing more seriously, > > > because obviously someone considered it being "ready to market". > > > > > > Last not least, I personally have no strong opinions about the > > > numbering scheme (anymore), so whatever decision we come up with, > > > I'm fine with either one. > > > > > > @Aki: The original plans were to release 1.0 after 0.9.3. I added > > > the 0.9.4 tag to JIRA, and that's how all of a sudden the plan > > > started to change ... ;-) > > > > > > Have fun, > > > JensG > > > > > > > > > > > > -----Ursprüngliche Nachricht----- From: Aki Sukegawa > > > Sent: Saturday, January 9, 2016 7:48 PM > > > To: dev@thrift.apache.org ; jfarr...@apache.org > > > Subject: Re: Thoughts on a 0.9.4 rc > > > > > > Great to hear that ! > > > I have a few local WIP that would be valuable for the release but I > > think I > > > can make it very soon. > > > > > > One thing I want to propose is to use a different versioning scheme, > > > something like 0.10.0. > > > > > > Last time, I saw users complaining like "Why such a change for *patch* > > > release ??" > > > And this time we have quite a few behavior changes like wire-format for > > > certain language+protocols or default generator flags for a language. > > > So 0.9.4 would induce wrong expectation among users. > > > > > > I understand the original intention of 0.9.x series and glad we're > > > almost > > > finishing this. > > > But if a different scheme communicates the release content better, > isn't > > it > > > worth compromising last a few release numbers before 1.0 ? > > > > > > > > > On Sun, Jan 10, 2016 at 2:46 AM Jake Farrell <jfarr...@apache.org> > > wrote: > > > > > >> What does everyone think about cutting a 0.9.4 release candidate in > the > > >> next week or so? > > >> > > >> -Jake > > >> > > > > > > > >
