Hi,
For those not on the subsurface mailinglist, you can read the first
part of this discussion here:
http://lists.hohndel.org/pipermail/subsurface/2012-May/000208.html
On 2012-05-03 17:58, Linus Torvalds wrote:
> It's the *ugly* and pointless breakage that I get so upset about. It
> makes things harder for everybody for no actual reason. And it is
> indicative of the same old "I don't think of libdivecomputer as a
> library, I think of it as a random collection of internal routines"
> problem.
>
> Interfaces are important. Even during development. They are doubly
> important when it's a library that other projects use.
Let's try to approach this discussion from another perspective.
In the past, the libdivecomputer library provided no official releases,
and there was just a single development branch (git master) where all
the work was done. This development model didn't work well for
applications, and therefore I introduced the new model with the 0.1.0
release. My idea was to proceed as follows:
1. We keep git master as the main development branch. This is where all
the work towards the next stable release happens. New features can be
introduced and backwards compatibility isn't guaranteed.
2. Stable releases (e.g. v0.x.0) are provided at the end of each
development cycle.
3. Whenever bugfixes for a stable release are necessary, a new release
branch is created. Only bugfixes are allowed here, and backwards
compatibility is maintained. Releases from this branch will increment
the micro number only (e.g. v0.x.y).
This development model would allow me to introduce
backwards-incompatible changes incrementally and also faster (e.g. no
need to delay breaking changes). Applications should stick to the stable
releases, and therefore require updating only when upgrading to the next
stable release. Any incompatible changes will be documented with the new
release. No more unexpected breaks anymore. Support for older versions
can be kept by conditional compilation based on the libdivecomputer
version macros.
I assumed this would be a huge improvement compared to the previous
situation, because it keeps the pain for applications to a minimum,
while still providing enough flexibility to commit work-in-progress to
the development branch. At some point, once we're all satisfied with the
public api, we can move to v1.0.0 and never break backwards
compatibility again. But let's concentrate on the road towards that goal
first.
If you (or anyone else) think this is not the right way to proceed,
please tell me what you would do different.
Jef
I'm having some trouble using the "universal" sample with my Aeris
Epic dive computer. After running, I get what appears to be correct
information for each dive, except for the samples. The depth is always
11.41, and despite the fact that my sampling interval is set to 1
second I only get a sample for every two seconds:
<sample>
<time>00:04</time>
<vendor type="5" size="8">5A0057025A005702</vendor>
<temperature>24.44</temperature>
<pressure tank="0">0.00</pressure>
<depth>11.41</depth>
</sample>
<sample>
<time>00:06</time>
<vendor type="5" size="8">5A00570257005702</vendor>
<temperature>24.44</temperature>
<pressure tank="0">0.00</pressure>
<depth>11.41</depth>
</sample>
I've compiled the samples on my machine and used the pre-built
binaries with the same result. I've also used the plugin from
diveboard.com to connect to my computer as well and had the same
problem. MacDive imports them just fine though. Odd, since I
understand both of these apps use libdivecomputer.
I'd very much appreciate any help. I'm hoping to develop some software
for analyzing this xml output as well as UDCF from the perspective of
the freediver. I've got some ideas for organization and visualization
that I think will be a lot more useful than the typical scuba-focused
software provides.
-Chad
