search

tschneidereit / SwiftSuspenders

NOTE: Find the offical repo at http://github.com/robotlegs/swiftsuspenders
https://github.com/robotlegs/swiftsuspenders
MIT License
280 stars 89 forks source link

Versioning #80

Closed darscan closed 6 years ago

darscan commented 11 years ago

Howdy.

Currently the version in the build properties file of Swiftsuspenders we have v2.0.0rc2stray2, but in the latest RL2 libs folder we have a dependency on Swiftsuspenders-v2.0.0rc3stray1.

However, in the RL2 properties file we seem to be depending on Swiftsuspenders-v2.0.0rc3stray1. And then in the Maven POM we're depending on 2.0.0-b4, and in our Buildr buildfile we're depending on Swiftsuspenders-v2.0.0rc3stray1.swc!

Have @Stray's changes been merged in? Should the version be bumped to v2.0.0rc3?

Stray commented 11 years ago

Yeah… sorry for all that confusion - been hoping Till would pull/merge/part-reject my pull request and release. As far as I know, they have not yet been merged sufficient to swap in a Till-build. v2.0.0rc3stray1 is the 'right' version (if Till strips out an optional param from instantiateUnmapped it shouldn't affect the framework). Apologies for not updating the Maven POM… the others should (and appear to) all be consistent with rc3stray1.

Sx

On 11 Nov 2012, at 23:42, Shaun Smith notifications@github.com wrote:

Howdy.

Currently the version in the build properties file of Swiftsuspenders we have v2.0.0rc2stray2, but in the latest RL2 libs folder we have a dependency on Swiftsuspenders-v2.0.0rc3stray1.

However, in the RL2 properties file we seem to be depending on Swiftsuspenders-v2.0.0rc3stray1. And then in the Maven POM we're depending on 2.0.0-b4, and in our Buildr buildfile we're depending on Swiftsuspenders-v2.0.0rc3stray1.swc!

Have @Stray's changes been merged in? Should the version be bumped to v2.0.0rc3?

— Reply to this email directly or view it on GitHub.

darscan commented 11 years ago

No problem at all - was just prepping all the buildfiles for a snapshot release, and wasn't sure what was potting. Locally I've been building RL2 against the head of this repo, and I haven't come across any problems or failing tests. Maybe your changes have been pulled in?

darscan commented 11 years ago

Besides, the POM is a funny one as there are actually two scrips (*nix and win) that install the SWC files from the libs folder into your local Maven repository with specific version numbers. So, the file in the lib folder ends up being installed locally as 2.0.0-b4 - which is what the POM depends on.

Stray commented 11 years ago

I don't think they have yet - they only affect deeply-nested injections so I don't think the RL2 tests cover the changes.

On 11 Nov 2012, at 23:58, Shaun Smith notifications@github.com wrote:

No problem at all - was just prepping all the buildfiles for a snapshot release, and wasn't sure what was potting. Locally I've been building RL2 against the head of this repo, and I haven't come across any problems or failing tests. Maybe your changes have been pulled in?

— Reply to this email directly or view it on GitHub.

darscan commented 11 years ago

Interesting.. perhaps that is why I've had injections injected as null without exploding - as I'm linking against the source and not the SWC.

Stray commented 11 years ago

Yup - unmapped should explode now unless you explicitly set a fallbackProvider or are using instantiateUnmapped();

The last set of changes affect the behaviour of instantiation of unmapped classes with dependency trees.

The last remaining controversy (afaik) is whether instantiateUnmapped needs a second optional param to tell you to also ignore mappings for the dependency tree. As Till rightly points out, you can just make a new injector with no mappings and a fallbackProvider to do this (as the injector does under the hood), but I think that could force folk to be injecting 2 named injectors around, which feels a bit icky. (To avoid the new Injector() overhead).

But I'll leave that to be determined… :)

Hrm… the only thing making me doubt this now (it being cause for your nulls) is that the newest commits of RL2 use methods that weren't available in SwiftSuspenders prior to October, though the deep-nested problem has only been fixed since then.

Curious...

On 12 Nov 2012, at 00:05, Shaun Smith notifications@github.com wrote:

Interesting.. perhaps that is why I've had injections injected as null without exploding - as I'm linking against the source and not the SWC.

— Reply to this email directly or view it on GitHub.