Re: Package status

> > If you want to relase this code as Stable, then give it > > that name > > and figure out a version# from there(1.0.0 would be appropriate). > > Don't feel forced to release an otherwise stable package as > > beta > > since you're < 1.0.0 :) > > Also, note that if you don't want to release this code as > > 1.0.0 > > yet, know that if you release a 0.9.8 as BETA, users who have set > > their prefered-state to "stable", will NOT get upgraded. As such, > > unless there's some major refactoring, and you think the code is > > stable, just relase it as such as 1.0.0 (stable). > I don't want to release a 1.0.0 version, because Wolfram > (the original author) has plans on a 1.0.0 version already > (see [1] and [2]), which will be different from 0.9.x. > > The changes I applied are (mostly) bugfixes, so I'd go > with 0.10.1. Anyway, I'm not comfortable with labeling > it as "beta" because of the reason you gave above, > and for the fact that it's been marked stable for ages. > I'm not too keen on using a "beta" label, because > it should be even more stable than latest "stable" release, > and hopefully I won't have to release another version > anytime soon. If it's a mere bugfix release, and not a feature-increase release, you just up the last digit, creating 0.9.8, with the same state as 0.9.7, stable. > Hence the question goes down to: > should packages released before the guidelines > follow them always and in every case? IMHO, those older packages should try and follow the rules as much as possible. With this package there'd be almost no way to follow ALL the rules, and in respect with the package roadmaps, the 0.9.8 version would be the best way to go from here. My 2c's Cipri