To me 1.0 means (in order of significance): 1. Build is fully cmake (no bootstrap.sh, etc.) 2. Python 3 supported 3. Modern C++ supported
That is of course just my wish list. The first one is the most significant given it impacts all users. On Sun, Jan 10, 2016 at 6:17 PM, Aki Sukegawa <ns...@apache.org> wrote: > 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 > > >> > > > > > > >
