search

paulirotta / Tantalum

Tantalum Cross Platform Library
12 stars 6 forks source link

RFC: release strategy #15

Open vivainio opened 11 years ago

vivainio commented 11 years ago

This is how I think we should release Tantalum going forward:

https://github.com/TantalumMobile/Tantalum/wiki/Release-strategy

(i.e. no JAR's).

Please approve/criticize in this Issue, and modify the wiki page accordingly

vivainio commented 11 years ago

Edited wiki page based on feedback from @satyambandarapu

paulirotta commented 11 years ago

Satyam and Kai, you have two different approaches to running the unit tests.

Can we run the same unit tests on device as we do with mocking on J2SE with the CI server? I would love to have device test also, but perhaps that is a different package of tests that run all in one Midlet. Less complex is always appreciated, but we might need to some thinking how to get the best of both worlds without splitting the unit tests into two groups.

vivainio commented 11 years ago

cc @satyambandarapu @kaiinkinen

kaiinkinen commented 11 years ago

My argument for having the J2SE-context is twofold a) it allows more tools and better automation b) it does force us to separate various concerns

A lot of the logic we're writing here should not be platform-specific, so having it run on the least capable platform, i.e. normal Java 2, we're open to the most possible usage scenarios. Having J2SE-tests also allow for faster feedback cycles, although there's still some work to be done to make the tests run really smoothly in the IDE. Running the tests on the emulator is necessary in most cases, but I think we'd like to restrict the cases to those where we actually want to test something device-specific (close-to-platform code), rather than generic (i.e. the SortedVector-tests).

@paulirotta about running the same tests on the device as in gradle. Unfortunately I don't think it's realistic, since a lot of the tests depend on annotation, reflection, mocking and such, so making those tests work well in the J2ME-context will probably prove to be an enormous task. We should maybe treat the JME-tests more like "integration tests", since they're kind of closer to this anyway, given the extra overhead of building an application and running it to execute them.

These are just my two cents. I personally happen to write code much faster and reliable when doing TDD, so I'm kind of biased here, but I do think providing this options is valuable, and as long as everyone agrees to how we maintain the codebase.

vivainio commented 11 years ago

I agree with @kaiinkinen. We need to be quite quality driven, which means we want modern tools for testing, coverage etc. It should also make development more fun and welcoming to external contributors.

It also keeps us honest to the cross platform mission :-).

kaiinkinen commented 11 years ago

One more thing about the release process. Since we're building in gradle, we actually get really good integration with maven. One way to do releasing would be to push library files, with sources and javadocs, to maven central. It's not likely to give huge adoption, but it would be more or less free for us, as long as we can deal with the version numbering. This would allow us to e.g. have a template project here in github, of the type "Clone this to start developing a Tantalum-enabled app". We could include all our work for the unit testing in the template project, which could hopefully tackle part of the "fun and welcoming"-task :) Hopefully, we could make a bigger difference by pushing for some higher level build tool adoption in other JME-projects this way.