RxAndroidBle is a great piece of software and has reduced development time for Ble projects and has increased stability and readability significantly.
I just want to ask, what the status is of the rxjava3 branch of RxAndroidBle?
It says it is a test branch and stale at this moment.
So is it not recommended to take the rxjava3 branch for production applications?
I wonder if there are future plans to concentrate on rxjava3, since on the RxJava page it says:
The 2.x version is in maintenance mode and will be supported only through bugfixes until February 28, 2021.
Greetings from t4rj4n
RxAndroidBle added support for RxJava3 in version 1.15.0 on 13. June 2022. All releases after that have had support for both RxJava2 and RxJava3.
You can find the releases on the Releases page on GitHub.
Related
I am currently using Tinkerpop 2.5 in my application to represent a graph in-memory and gremlin to query it. This application will go into production at end of July 2015. I am confused if I should use 2.5 or 3. Currently Tinkerpop 3.0.0 is in M7 release. I don't see any information on the GA release schedule.
At this time, TinkerPop 2.x is basically in maintenance-mode only (i.e. we've generally frozen development short of major bug fixes). All effort is focused on TP3 and getting it to GA. GA has been somewhat delayed as TinkerPop moves to its new home as an Apache project: http://tinkerpop.incubator.apache.org/
Unfortunately, we can't provide much certainty for when GA will be available, so this leaves people starting a project and trying to make the choice between TP2 and TP3 a bit difficult. I can say that if you use TP2, it has good stability and a very wide number of vendors who support it. If you use TP3, expect some turmoil in the API on the way to GA and keep in mind that, at this time, you don't have a lot of vendor support for the interfaces though many vendors are committed to having TP3 implementations when GA is in place: http://www.tinkerpop.com/docs/3.0.0-SNAPSHOT/#_graph_vendors
UPDATE: TinkerPop 3.x was released into GA in July 2015 and can now be considered production-ready. There have been multiple releases since that initial one. Latest developments can be found on the project home page: http://tinkerpop.apache.org/
I am interested in creating a desktop application using HTML5+webkit, and I'd like to be able to build a stand-alone executables for various target platforms like a .exe file for Windows and a .dmg image for Mac OS. I have played around with node-webkit, which seems nice except for the packaging / distribution portion. I also stumbled on TideSDK, but that project seems to be inactive. For example, the latest release I saw was a beta from November of 2012. Yet, it seems the core developers have switched to developing TideKit instead.
Does anyone here know if TideKit is intended as a replacement for TideSDK? Is TideSDK going away? etc.
Well, TIDE is now officially a dead project. I just got this email about 15 minutes ago.
TideKit.com and TideKit have been discontinued.
TideKit was software for developing apps for all platforms
simultaneously with a single base of code written in JavaScript.
The scope and complexity of the product made it difficult to
assemble the platform all at once. This stemmed from a holistic
approach to app development for all platforms. While creating a
platform for JavaScript developers, much of the core engineering is in
a variety of lower level languages that affect the speed of
development. We considered delivering parts of our platform as we
reached milestones, but this was not suitable for the start of trials.
We were widely criticized for not revealing our technical innovation
in advance of our release. In a competitive environment, revealing
advantages as you go can also mean assimilation as you go. We had
already witnessed how quickly our technical advantages could be
assimilated by competitors to our open source TideSDK product.
Therefore, we held back with a view of delaying the duplication of
features by competitors, increasing our technical barriers and working
to protect our IP and business case until we felt we were ready.
In a startup, we talk about a Minimum Viable Product (MVP). In our
case, our minimum viable product was much larger and more difficult to
achieve. In total, approximately three years of research and
development was committed with multiple developers working greater
than full time hours. A factor that extended the development was an
expansion of scope that aimed to lower friction in the app development
process.
In Feb 2014, we created a system to queue developers with
reservation system for the earliest possible access to TideKit. Our
goal was to provide an early trial when it became available. Since the
development itself was complex, we could not provide a date when
ticket holders could start the trial process – but it would be
following our betas, then moving forward as we scaled the platform.
We were clear with our language on the site concerning reservations.
As a result, we expected little confusion about what was being
purchased, our expectations of timing to market, or the terms of
purchase for a reservation ticket. Purchasers were not paying for our
product at this point, but for their position in a queue for a trial
of our new technology. We also included a refund policy to ensure the
terms of purchase for your ticket were available. The wait has been
long, but not nearly as long as other difficult engineering challenges
including Myo that pre-sold their product and were also delayed before
successfully rolling out.
Throughout the development cycle we provided updates of our status
via posts roadmap page, email to our ticket holders and communications
on our social channels. We did our best as a team to open ourselves to
questions and maintain a social presence.
At the end of May 2015, we communicated our strategy to execute a
series of focused betas that would have seen the platform revealed
publicly and incrementally. We were at a stage that parts of the
platform needed developer feedback as we rolled these out
consecutively.
In the days preparing for our first public beta, we recognized the
extent to which our brand had been poisoned by our timing to market. A
campaign of negativity that had begun several months earlier with
followers and ticket holders had taken its toll on our team, brand,
and business.
We believed the beta releases would soon bring an end to the
negative talk. On July 8 and 9 we faced further eruptions on social
media that reached the tipping point. With the discussion no longer
about the product nor its future, this was far more serious.
We failed to bring the product quickly enough for you. As a result,
we came to the serious decision to discontinue TideKit and dissolve
our company.
We wish to thank everyone involved that worked on the product and with
our team. This includes businesses, entrepreneurs and supporters of
our vision for app development.
Your TideKit Team
you are right, TideSDK is aging and pretty inactive today. And you're also right, we as a core team completely focus on TideKit now. TideKit is the future!
If you want to know the full story about why we stopped working on TideSDK and started TideKit, I recommend you to read our first Q&A. There you'll also find an answer about how we compete with node-webkit:
https://blog.tidekit.com/post/your-questions-our-answers-01
We've just reached the highest HTML5 score any app development platform ever achieved. If you want to know more about builds, like the ones you mentioned for Windows and OS X, you should read this
Desktop Builds
https://blog.tidekit.com/post/from-a-desktop-perspective-tidekit-for-tidesdk-developers
There is a new kid on the block for this sort of projects: atom-shell Based in nodejs and used to create the great Atom editor
Technical differences with node-webkit: https://github.com/atom/atom-shell/blob/master/docs/development/atom-shell-vs-node-webkit.md
Presentation at JSLA about "Native NodeJS Apps": http://vimeo.com/97881078
If you look at this blog post, they talk about how unsustainable the economical situation is
http://www.tidesdk.org/blog/2013/04/11/tidesdk-in-numbers/
and I can't find the tweet that was stating the reasons behind the transition from one project to another. But I guess that the blogpost speaks for itself.
Anyway, I'm delivering a project written in node-webkit ( because I starded on Tide but for the obvious reasons I had to switch ) and I'm using grunt for packaging and in the end is not that bad.
Electron (http://electron.atom.io/) is the new way to go.
I also had an app running on TideSDK (https://github.com/vinyll/worktimer.titanium) and I'll have to migrate it to Electron.
I rolled out JMock at our company, and many folks are using it with success. The version we are using is the latest stable release, which is 2.5.1. That was released in August 2008. Since then, two release candidates came out, 2.6.0RC1 and RC2 in 12/08 and 9/10, respectively. That seems like a long time for a release to be a "candidate." I'd like to update to 2.6.0, but my company is hesitant to use a product that is not a "stable" release. I share their concerns.
I have two questions about this. First, for anyone using the 2.6.0 RC1 or RC2 releases, have you found any evidence of instability in these versions?
Second, and this is more for the folks who created the tool, why is 2.6.0 considered still a release candidate and are there plans to release a "stable" 2.6.0?
Thanks!
Ken
2.6.0.RC2 seems to be perfectly stable. I'd have no issues with using that in anger.
I understand there are plans to push 2.6.0 to a full release, and that it's just a matter of free time to do it...
We're trying to get a release out but are short of maven help
I've come across the following excellent blogpost on a git workflow model that works with release, develop, feature and bugfix branches: http://nvie.com/posts/a-successful-git-branching-model/
It sounds like an excellent workflow and I am really eager to try it in production but one paragraph caught my attention and leaves me wondering.
It is exactly at the start of a release branch that the upcoming release gets assigned a version number—not any earlier. Up until that moment, the develop branch reflected changes for the “next release”, but it is unclear whether that “next release” will eventually become 0.3 or 1.0, until the release branch is started. That decision is made on the start of the release branch and is carried out by the project’s rules on version number bumping.
I'm wondering, how does this way of working reflect in your ticketing and bugtracking system? In JIRA and BugZilla we create "versions" that a ticket can belong to. Prior to switching to a release branch, what version does a ticket belong to when in the development branch? Do you have a version in your issuetracker for every branch?
And what about feature tickets that you know you are going to implement not in the upcoming release but in the release thereafter? Am I supposed to create a version "upcoming" and "future" for this kind of tickets?
Any insight in how this branching workflow reflects in ticket/issue management is appreciated!
Am I supposed to create a version "upcoming" and "future" for this kind of tickets
This is the basic idea. The key idea is that a current development will include some features part if the next release, and some which will ultimately be too complex and/or not ready in time and/or depending on other features which won't make it in said next release.
This is a bit like branches 'pu' and 'next' in the git repo itself.
In short, a feature ticket is rarely issued to a specific release number, while a bug fix ticket can be (2.1 for fixing release 2 for instance).
According to http://mdbf.codeplex.com/:
"Due to the organizational restructuring of the team that developed and supported the Mobile Device Browser file, we will no longer have the resources to support and update this CodePlex project. The team will be providing two more releases – one on the 27th July 2010 and the final release on the 24th August 2010.
We would like to thank everyone who used our product over the past year and a half. We would also like to thank everyone who contributed to the discussions and raised issues on our data."
Does this project live on someplace else or is there an equivelent project?
51degrees claims to have a replacement, but it isn't made in the same way (via .browser definition files).
MDBF is still hosted on codeplex though - they reopened it by demand, but there isn't any promises of any updates that could occur.