The currently available release is quite old now, so I'm wondering if it isn't time to do a new release. The mode tracking code is too new, although it has been running on my system for a while, so I thought to use the pre_mode_tracking tag to generate a 0.7 release.
This brings me to several questions:
- What's the numbering scheme? - Is 0.10 deemed acceptable? Or is 0.9 considered to be last before 1.0? - Do the version numbers mean anything wrt guaranteed APIs? (like, for example, in the APR project; see http://apr.apache.org/versioning.html) - What requirements are there for a 1.0 release?
Thanks for your reactions!
bye,
Erik.
On Mar 20, 2005, at 3:57 PM, Erik Huelsmann wrote:
The currently available release is quite old now, so I'm wondering if it isn't time to do a new release. The mode tracking code is too new, although it has been running on my system for a while, so I thought to use the pre_mode_tracking tag to generate a 0.7 release.
This brings me to several questions:
- What's the numbering scheme?
- Is 0.10 deemed acceptable? Or is 0.9 considered to be last before
1.0?
- Do the version numbers mean anything wrt guaranteed APIs? (like,
for example, in the APR project; see http://apr.apache.org/versioning.html)
- What requirements are there for a 1.0 release?
Thanks for your reactions!
I think 0.10 would be quite acceptable. So far there have been no promises of guaranteed APIs; I don't think that it'd be fair to guarantee such a thing without any documentation!
As far as a 1.0 release: mode tracking is a very good thing. I'd like to also have some kind of last-seen or last-spoke tracking, and documentation. Needless to say I've no time to work on any of this myself :-) -- Brian Mastenbrook brian@mastenbrook.net http://www.iscblog.info/
On Mar 20, 2005, at 3:57 PM, Erik Huelsmann wrote:
The currently available release is quite old now, so I'm wondering if it isn't time to do a new release. The mode tracking code is too new, although it has been running on my system for a while, so I thought to use the pre_mode_tracking tag to generate a 0.7 release.
This brings me to several questions:
- What's the numbering scheme?
- Is 0.10 deemed acceptable? Or is 0.9 considered to be last before
1.0?
- Do the version numbers mean anything wrt guaranteed APIs? (like,
for example, in the APR project; see http://apr.apache.org/versioning.html)
- What requirements are there for a 1.0 release?
Thanks for your reactions!
I think 0.10 would be quite acceptable. So far there have been no promises of guaranteed APIs; I don't think that it'd be fair to guarantee such a thing without any documentation!
As far as a 1.0 release: mode tracking is a very good thing. I'd like to also have some kind of last-seen or last-spoke tracking, and documentation. Needless to say I've no time to work on any of this myself :-)
Last-spoke tracking can easily be added with the mode-support I recently added.
Last-seen is more cumbersome, since it requires a (theoretically unbounded) list of nicks having been in a channel: depending on what you want to remember for each nick, that can become quite some data. Currently 'user' objects disappear when the user quits or leaves the last channel, limiting the list of users-in-memory to all active users...
As far as documentation is concerned: I'm quite busy too, but I'll see what I can do.
bye,
Erik.
Hello Lispers,
I'm new to this project. And after sending that one patch and after I got cl-irc to work for my tests I joined to this list.
Cl-irc is nice interface for IRC. It works great and it didn't take too long to do simple IRC bot. Thanks!
Couple of things I want to bring my opinnion into:
On Sun, Mar 20, 2005 at 10:57:49PM +0100, Erik Huelsmann wrote:
This brings me to several questions:
- What's the numbering scheme?
- Is 0.10 deemed acceptable? Or is 0.9 considered to be last before 1.0?
It's common practice that after 0.9 comes 0.10. So it's acceptable.
- Do the version numbers mean anything wrt guaranteed APIs?
If it's documented, then yes. Again, it seems to be common practise that software with version number below 1.0 can change API between versions. It's still in development after all. Then 1.0 should have same API and new API can be introduced in 2.0. Does this make any sense?
- What requirements are there for a 1.0 release?
- Extensive documentation (Wiki might be good way to get contributions?) - Stable API. No need to do changes before 2.0? - Bugfree code?
Hopefully I can get myself to do something useful and contribute code to your project.
Cheers,
Hello Lispers,
I'm new to this project. And after sending that one patch and after I got cl-irc to work for my tests I joined to this list.
Cl-irc is nice interface for IRC. It works great and it didn't take too long to do simple IRC bot. Thanks!
Couple of things I want to bring my opinnion into:
On Sun, Mar 20, 2005 at 10:57:49PM +0100, Erik Huelsmann wrote:
This brings me to several questions:
- What's the numbering scheme?
- Is 0.10 deemed acceptable? Or is 0.9 considered to be last before
1.0?
It's common practice that after 0.9 comes 0.10. So it's acceptable.
Yes, some projects do use 0.9 -> 0.10 -> 0.xx -> 1.0 others (SBCL, APR) use 0.9 -> 1.0. The former is fine (a bit more relaxed) by me, I just wanted to know... Since Brian sent his reaction too, I think we have consensus now to go the former route.
- Do the version numbers mean anything wrt guaranteed APIs?
If it's documented, then yes. Again, it seems to be common practise that software with version number below 1.0 can change API between versions. It's still in development after all. Then 1.0 should have same API and new API can be introduced in 2.0. Does this make any sense?
Yes, that's almost 1 to 1 what is in the URL I referred to. I'd be very happy if there were no guarantees until 1.0 though. That would make life a *lot* easier when trying to go to a 1.0 from where we are now :-)
- What requirements are there for a 1.0 release?
- Extensive documentation (Wiki might be good way to get contributions?)
I have no idea about how well a wiki will help to get contributions in terms of documentation.
- Stable API. No need to do changes before 2.0?
I think the strategy in the URL I referred to is actually quite nice. I have some experience working with that scheme. It means you can't change, but you can *add* new interfaces/api's.
- Bugfree code?
Does that exist? :-)
Hopefully I can get myself to do something useful and contribute code to your project.
All contributions are welcome ofcourse! If you start anything major, could you please send a notification to the list? That way we can prevent duplication of efforts.
bye,
Erik.
-
Brian Mastenbrook -
Erik Huelsmann -
Ossi Herrala