Steps to a 6.x-1.0/7.x-1.0 Release

In the race to make this request (which I eventually yielded to halstead ;)), I looked at the 6.x issues in the queue. They all seem to be feature additions of some kind, and not really bugs with how it works right now. As such, it doesn't look like there's any really outstanding issues blocking a 6.x-1.0 release, from what I can tell. Do enlighten me though, if there's anything beneath the surface that I'm not seeing. :)

The 7.x issue queue, however, is a completely different critter...

This is a tough decision. It's true that D6 hasn't changed much, but that's because we're still developing the "actual" Libraries API functionality in HEAD/D7, and that may still take a while. However, the plan is basically to backport that functionality to D6 at some point -- which would mean that we'd introduce a huge amount of new features and functionality into an already "stable"/official release branch, if we'd do a 6.x-1.0 now. And since D6 does not support version-specific module dependencies, other modules (like Wysiwyg) wouldn't really be able to require that Libraries API is installed; i.e., >=6.x-1.1

Of course, one could argue that there can always be a 2.x branch, but hm... to me it feels like 1.0 would be calling out something official that was never intended to be that limited in functionality, you know... ;)

Curious to hear what @tstoeckler thinks about this.

Of course, one could argue that there can always be a 2.x branch, but hm... to me it feels like 1.0 would be calling out something official that was never intended to be that limited in functionality, you know... ;)

I feel the same. On the other hand, it seems a release is actually needed.
Maybe it is an option to tag a DRUPAL-7--1-ALPHA1, which could run on drupal.org? AFAIK know the whole project suite currently doesn't run on an official version.
We could basically do this:

patch -p0 < patch-to-revert-all-api-additions-of-the-last-months.patch
cvs commit -m "Preparing the 7.x-1.x-alpha1 release"
cvs tag DRUPAL-7--1-ALPHA1
cvs update -A
patch -p0 -R < patch-to-revert-all-api-additions-of-the-last-months.patch
cvs commit -m "Back to HEAD"

Or something like that.
I'd personally like that better than a 7.x-1.0 release, but in the end, it's just a friggin' number, so I don't feel strongly either way.

Either way, the good thing about releasing some form of something is that we can do stuff like #961476: Make libraries_get_path() return FALSE by default without breaking anyone's code. So, I guess a release would be good for "both parties" in the end.
As stated, I'd vote for 7.x-1.x-alpha1 over 7.x-1.0.

D'uh, I just realized this is about 6.x-1.x (?!).
Is there anything wrong with using the Drupal 6 alpha version for now?
It's really like 20 lines of code, which have worked fine for a year (?) for a few thousand people according to the usage stats. So despite being tagged as alpha it should be fine for production-use, IMO.

Would a little sentence on the project page help?
Again, not tagging a 1.0 release is purely an aesthetical decision, but 'being perceived as alpha quality software' on the other hand, is also not that striking an argument to overrule that decision, at least IMO.

Thought about this. I think I'm going to tag a 6.x-1.0 later tonight, and also branch HEAD off into DRUPAL-7--1, remove all additional functionality of HEAD, and tag that as 7.x-1.0. That is, because the basic functionality is actively used and needed by other modules already, so we need a D7 release anyway; and work in HEAD will most likely still take a while to get into a state that works for other modules to actively use it, so HEAD will turn into 2.x when it's ready.

Any objections?

Knock yourself out, no objections at all. :)
I just turned Skype on, so in case you need any minute-to-minute patch reviews or something (just in case) be sure to give me plug.
/me looks forward to remove cruft from libraries_get_path() :)

Done. :)

Not sure whether we should/need to clarify the state of 1.x with regard to HEAD.