Hi folks,
Since the state of Barry is getting rather stable, and considering the
upcoming major releases of software such as OpenSync, and even Debian
planning the release of Lenny soon, I've been giving Barry's version
numbers some thought.
(Question for Debian folks: it looks like OpenSync 0.22 is the version
that Lenny will ship... is this correct, or am I just dreaming?)
Here's my plan at the moment. I'd appreciate feedback on areas that I may
have overlooked.
Version 0.14
The next version, fixing some niggling bugs and adding more
documentation to the mix. Binary package changes to match
distro best practices as well. libbarry will be called
libbarry0.
Version 0.15
More bug shakeouts, perhaps some quick integration of some
of the contrib/ software. Basically tidying up.
Version 1.0
If there are no show stoppers in 0.15, we bump the version
to 1.0, and this becomes a stable library release, with
some API and ABI backward-compatibility guarantees.
This will be handled as documented in doc/VersionNotes.
Bugfixes will be released as 1.1, 1.2, etc.
Version 1.50
As mentioned in doc/VersionNotes, the new development
continues on as 1.50, 1.51, 1.52, etc, with the goal of
a stable version 2.0.
This is where we'll implement a new plugin for OpenSync 0.40,
and we'll have a clear demarcation point for folks still
using OpenSync 0.22.
Version 2.0
Sometime off in the future. :-)
Some questions for users:
1) How valuable is it to be able to install "Barry 0.13" as one
group? Would it be confusing to install libbarry 0.13,
barrybackup 1.15, and opensync plugin 0.92?
2) In your opinion, what do you consider the most important feature
that is currently preventing Barry from being considered
version 1.0-class software?
I have a number of options here, for helping Barry follow along with
dependencies:
A) Keep Barry components in lock step, and proceed as above, with
version 1.0
B) Split the Barry components into separate repositories and
package them separately, so that the opensync plugin could
have it's own version 1.0 independent of libbarry.
C) Create a whole new plugin tree, so that both an 0.22 plugin and
an 0.4x plugin come in the same Barry source tree.
I think plan A is the cleanest and least confusing of the choices, but
I'm interested in your thoughts, so I don't miss anything obvious when
I solidify the plans.
I'm expecting version 0.14 and 0.15 would come out in the next month at
the latest, so that Barry's development tree is ready for OpenSync 0.40.
As for known issues...
There are currently 4 known issues that are listed in Barry releases.
None of them are hindering a 1.0 release, in my opinion, and a 1.0 release
would fix one of the issues, since OpenSync would have a proper upgrade
path for Fedora 9.
Here's the list of known issues:
1) Restoring backups for some databases on newer Blackberries
doesn't work (for example, on the 8120, 8700g)
2) Syncing is not supported on Fedora Core 9, since they packaged
the OpenSync 0.3x devel tree
3) Password support when using Blackberry as modem is experimental
4) Accessing the database (such as during a backup) while copying
files using the usb_storage kernel module may cause some
Blackberries to spontaneously reboot
#1 depends on reverse engineering work, but I expect new Blackberries
to regularly require new work, so a list of supported devices would be
suitable for version 1.0, and newer devices would be supported in newer
Barry releases.
#2 would be fixed with this plan.
#3 may still be true, but there haven't been a lot of bug reports about
modem password support... so far so good.
#4 is more of a firmware or a kernel issue in my opinion, and out of
our control.
I've pasted doc/VersionNotes below, for reference.
Thanks,
- Chris
doc/VersionNotes:
Barry is primarily intended to be a library, for any application to
access Blackberry devices. There will be an OpenSync module built
on top of this, plus some command line utilities, and possibly a GUI,
but initially Barry is a library, and must be versioned accordingly.
Additional applications built on top of Barry may be versioned separately.
Most operating systems can handle two library version numbers: major.minor.
They use these numbers to determine which library is compatible
and most recent.
Therefore Barry will be versioned the same way, the major version
number indicating a backward incompatible change to the library.
Version Numbering Plan:
-----------------------
Alpha development will occur on major version 0, incrementing the
minor version only until stability is reached.
When the 0.x series is stable, as a special case, the highest
stable 0.x version will be released as version 1.00. User-
readable version strings in the library and applications will
be changed to 1.00, 1.01, 1.02, 1.05, etc, but the library
version in src/Makefile.am will stay on the 0.x series.
Bugfix releases for this stable series will continue from there,
using 1.01 in user strings, and 0.x in the src/Makefile.am.
A new development branch will be started with the version 1.50,
and both src/Makefile.am and the user strings will match again.
From then on, development will continue on odd numbered major
versions with incompatible changes allowed. When stable, version
1.x will become 2.0, and the 3.x branch will be opened.
Due to limitations in remaining portable across as many operating systems
as possible, Barry will discontinue its 3-number version scheme as of
version 0.4.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Barry-devel mailing list
Barry-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/barry-devel
