If the files are in the root level then both bower and php will always use the trunk version and not the given released version. I really do not like how both of these packaged systems behave and do not consider for anything outside of just a repo with php or js code. Also the js code in its current form does not contain the actual packaged source that would be needed by the bower file (the generated dist/* files).
We can avoid pull requests to these repositories by not enabling the mirroring of them at github. Another option that might be a lot easier looking at the internals of both could be from out svn dist repo, something like https://dist.apache.org/repos/dist/release/thrift/x.x.x/lib/php/composer.json https://dist.apache.org/repos/dist/release/thrift/x.x.x/lib/js/bower.json This would allow us to keep them per release and also not enable pull requests and does not open up another repository that needs to be maintained, just a package step when deploying the given release. I'll look into this further and see if dist.a.o has any requirements such as only tar packages or not due to mirrors -Jake On Fri, Apr 4, 2014 at 8:03 PM, Roger Meier <[email protected]> wrote: > I agree with Jake, splitting up will make it more difficult to mange and > ensure cross language interoperability. > It's hard enough to manage the codebase and push things forward. > > I think we should not add additional repos. > Get additional pull requests for other repos? > How to handle all of this? > How to explain to the users? > > Just put bower.json and composer.json within root folder to simplify > shipment of these libs. > Mission complete! > > -roger > > Quoting Jake Farrell <[email protected]>: > > I would like to avoid the situation where we have a separate repo for each >> client lib which would make building, cross testing and maintaining >> extremely difficult. As long as it clear in a README included in these >> repositories that they are not for development and are only for released >> versions then this sounds like a reasonable approach. >> >> -Jake >> >> >> On Fri, Apr 4, 2014 at 11:46 AM, Randy Abernethy >> <[email protected]>wrote: >> >> Hey All, >>> >>> Sounds like we have a workable compromise which will make thrift easy to >>> install in PHP and JavaScript and keep the thrift master root clean. The >>> fact that composer.json and bower.json need to be in the repo root has >>> inspired the creation of thrift-php and thrift-js repos for releases. >>> Each >>> of these repos will be updated with every thrift release allowing any >>> version up to the current release to be installed. >>> >>> Let me know if the process and code below sounds right to everyone (this >>> is the PHP example but you can extrapolate the JS process): >>> >>> *When 0.9.2 is released we will:* >>> {code} >>> 1. git clone thrift-php >>> 2. cd thrift-php >>> 3. cp ../thrift/lib/php/{*, composer.json} . >>> 4. git add -A >>> 5. git commit -m "thrift-0.9.2" >>> {code} >>> >>> All of the PHP eco system installers and dependency managers will point >>> to: >>> https://github.com/apache/thrift-php >>> >>> The composer.json will be checked in to the master in thrift/lib/php. The >>> composer.json contents will need to be relative to / so that it works >>> when >>> copied to thrift-php. The following is the proposed composer.json >>> contents: >>> >>> {code} >>> { >>> "name": "apache/thrift", >>> "description": "Apache Thrift RPC system", >>> "homepage": "http://thrift.apache.org/";, >>> "type": "library", >>> "license": "Apache-2.0", >>> "authors": [ >>> { >>> "name": "Apache Thrift Developers", >>> "email": "[email protected]", >>> "homepage": "http://thrift.apache.org"; >>> } >>> ], >>> "support": { >>> "email": "[email protected]", >>> "issues": "https://issues.apache.org/jira/browse/THRIFT"; >>> }, >>> "require": { >>> "php": ">=5.3.0" >>> }, >>> "autoload": { >>> "psr-0": {"Thrift": "src/"} >>> }, >>> "target-dir": ".", >>> "minimum-stability": "dev", >>> "extra": { >>> "branch-alias": { >>> "dev-master": "0.9.x-dev" >>> } >>> } >>> } >>> {code} >>> >>> Please comment if you see problems with this process! See THRIFT-1743 for >>> more discussion. >>> >>> Thanks, >>> Randy >>> >>> > >
