[Libusbx-devel] Keeping the 1.0.9rc3 tag

[Pete Batard]

On 2012.03.24 23:29, Xiaofan Chen wrote:
> Wiki and libusbx.org are fine.

Not really. Please have a look at the following:
http://wiki.libusbx.org/index.php/Main_Page
http://www.libusbx.org/

Also we need to plan at 48 hours after we update the DNS entries for 
propagation, else some people may still end up on the old server.

> With regard to 1.0.9 release, I think the mainline git plus a few
> minor things (e.g.: xusb, Hans' patches, etc) should be fine.

Well, my plan for 1.0.9 is a "feel good" release, for us, i.e. just a 
few minor addons with what currently exists in mainline, to confirm that 
we can produce a tarball that may look usable by developers.

Then I'd like 1.0.10 to be another small-diff release, that takes care 
of versioning, because I think it will be critical that we have some way 
to differentiate ourselves from libsub from the version alone as soon as 
we are public. This will also ensure that, whatever Peter does, we are 
one step ahead in terms of version, which may matter for people who 
don't have a clue about the fork, and will be inclined to use the 
library with highest version. If we want to be successful, we must 
consider these kind of aspects as well.

My thinking is that having we should be able to use the nano for that 
(obviously, we're not going to break major/minor) with an offset (eg 
+10000) and the git distance to root should solve both the problems of 
being able to know *exactly* which commit the library came from, even if 
built from git, if generated against mainline (if not, then it's a fork, 
and since anything can happen in a fork, of course we don't care about 
version conflicts there), as well as being able to know whether someone 
is using libusb or libusbx.

As you are undoubtedly aware, not all developers we support seem to be 
able to tell us what library they are using or where exactly they got it 
from, so making it easy for them to be able to tell us should help, and 
will avoid us pondering "What £$%^&*(&% version of libusb(x?) is that 
person using?!?".
IMO, we shouldn't go public before we have sorted a better versioning 
than what libusb has.

> One relatively simple thing to do with 1.0.10 is to bring HID
> back to the Windows backend and call it 1.0.10 along with
> further bug fix for Mac OS X and Linux.

I'd plan that for 1.0.11, which would be the first release with major 
features added (or re-added).

> Just generate it and upload it to Sourceforge.

I'm very weary of a "just do it" when I have no idea of how complex it 
might be. Maybe it's trivial, maybe it's not. Call me cautious, but I'm 
not going to trust people on blind faith and take a bet that it's going 
to be straightforward before we actually do it.

> Daniel does it for libusb.
> And Travis has done it for libusbK.
> http://libusbk.sourceforge.net/UsbK3/index.html

Good for them. Still doesn't tell us how long it will actually take for 
us to do it. I've seen enough of "it's just a 5 mins job" that actually 
took days to complete, so I will add a safety margin just in case, if 
you don't mind.

> With the above documentation, Travis and I think Wiki
> are not that necessary.

I beg to differ. Especially as libusb.org is out. We are seeing users 
not getting information as a result, and running into known problems 
that they would have been able to figure out themselves otherwise 
(Renesas driver issue). At the very least I want to have the windows 
backend page duplicated, and I have to redo it again.

> But new Sourceforge has Wiki
> as well so libusbK has a placeholder here.
> http://sourceforge.net/p/libusbk/wiki/Home/

And as I previously stated, libusbx also has MediaWiki installed:
https://sourceforge.net/apps/mediawiki/libusbx/index.php?title=Main_Page

> Bug report system: The new Sourceforge interface has it.
> http://sourceforge.net/p/libusbk/tickets/

Well, we have the choice between trac, tracker, and MantisBT for bug 
tracking. I'd like to avoid picking one at random, since we'll be stuck 
with it. Anybody wants to have a look at those and try to find the one 
that may suit us best?

> First impressions are critical. But you can give good impressions
> by providing reasons why you think you are better.

Yeah, right, as if yet another verbose speech from me (if I'm the one to 
do it) will entice people to try libusbx...

Actions are better than words, and having something that looks at least 
a little bit polished when we publicize will go a long way. We are 
competing with an existing product, so let's make sure to try to 
demonstrate that we are better rather than promise we're going to be.

> All in all, I am okay with not to officialize things before the
> 1.0.10 release. But currently my idea of 1.0.10 release is
> quite simple

Same here, even more so as I don't plan HID before 1.0.11.

If we have 1.0.9 around April 1st, then I'd see 1.0.10 about 2 weeks 
after that, counting time to set versioning up, wiki, bug tracking and 
other stuff that I'd rather have operational before an official 
announcement.

When I have a chance, I'd also like to set a wiki page with the current 
plan for releases, and what we think should go in each of them, so that 
we all can be on the same page and get an estimate of the task ahead.

Regards,

/Pete