as mentioned in  we should have a code-freeze period of a few days
before we do the final release.
Release for UPS.1.0.0.Final date will be August 26th.
I'd like to do the code-freeze tomorrow(Tuesday, 19th) evening. I'd like to
create a 1.0.0.Final tag (or a branch) and only
'blocker' or 'critical' fixes should be allowed to be merged during that
time (to that particular branch/tag).
Basic goal: minimize risks!
(The JIRA tickets for the umbrella "Mobile Push 1.0" are almost all around
Quickstarts and our docs, see )
Once the 1.0.0.Final is released, I'd like to create a 1.0.x branch for
follow-up releases, as needed (see ).
The version number on the "1.0.x" branch will start with 1.0.1-SNAPSHOT
On MASTER branch, I'd like to set the version to 1.1.0-SNAPSHOT.
Fixes done on the 1.0.x branch will be merged/cherry-picked MASTER branch
Moving forward to our next 1.1.0 UPS release, on MASTER, we will be working
on new features, like:
* More analytics
* More mobile network (Windows, Kindle, etc)
* JavaEE7 updates (focus on WildFly / Undertow, ConcurrencyUtils, etc)
* Alternative Datastores (like Mongo) ?
Any thoughts ?
Ideally we would like to quit using the Robolectric Android stubs and
begin using Google's Android APIs for linking and testing. This is one
of the reasons that the unit tests havn't been brought over to the
modules YET. Over the weekend (between family duties and internet
issues) I did a lot of research and coding towards moving our tests into
the module packages. With the release of X86 emulators and stability
Genymotion, I think that using solely integration test projects for our
testing is now doable.
The Android SDK (current, ANT/Eclipse based) way is to have a separate
test project. The Android SDK (future Gradle based) way is to have your
tests in a test package. The maven way (Maven based Android builds) is
to have a parent project with two children: one child being code and the
other child being tests.
Currently we have one BIG integration test project which contains all of
our integration tests. I think that we should move the tests out of our
monolithic project and into the modules where they probably belong. I
also propose that we make each module in the two child project pattern
that then Maven based builds recommend. When it is time to move to
Gradle then we can just fiddle with sourceSets and kill the Maven build.
>>Phone:404 941 4698
>>Java is my crack.