From: Christophe R. <cs...@ca...> - 2012-09-03 11:46:39
|
Hi, In the great tag game that is release management, I'm it for a while. I plan to do monthly releases, starting at the end of this month, probably with a shortish freeze for testing: is there anyone reading this who has interest to perform any kind of dedicated testing at all (library maintainers, application deployers) who would be able to systematically test things before a release? I am also tempted to mess with the version number scheme, because I find 1.0.x as x tends to infinity slightly odd -- but I recognize that there may be practical reasons for not doing so: if anyone would be inconvenienced by a change to 1.y or maybe even 2.y, please say so. Cheers, Christophe |
From: Paul N. <pn...@va...> - 2012-09-03 15:34:48
|
Hi there, 1. Not sure what you.quite mean by systematic testing- I'm assuming you mean automated testing? Or perhaps some kind of well defined test plan? I currently keep a osx 10.6 machine up with Jenkins running cl-test-grid. I can add a make tests job for sbcl no problemo. I can also configure a sbcl build from other ( free) lisps if that's something that needs testing. I am willing to keep a x86 32 linux vm up for CI building/testing. That is no big deal! I may be able to dig up a 64 bit Linux as well. I am trying to get a PPC osx machine for CI as well. Hopefully that will help expose byte-ordering bugs. N.b.: IBM has a class of high powered Linux PPC64 servers that I'd like to make sure Sbcl can run on; since I don't have > 20k$, a Ppc osx is as good as I can do at home. So in sum: I can provide a CI array of 1 osx 10.6 x86, 1 Linux ( Debian) 32-bit; upcoming, 1 PPC osx 10.4 ( or so ), and maybe a amd64 Linux if needed. I don't have ready access to a bsd or Solaris/Illumnos box right now. If I had access, I could get them integrated in a CI system. Please let me know if this stuff would help. 2. As a user, I find 1.0.n, n -> inf fairly odd. :) One scheme that is used and may be a good fit is 'Semantic Versioning' http://semver.org/. Another scheme I personally like is just having a counter incrementing on release. Regards, Paul Nathan Sent from my iPhone On Sep 3, 2012, at 4:31 AM, Christophe Rhodes <cs...@ca...> wrote: > Hi, > > In the great tag game that is release management, I'm it for a while. I > plan to do monthly releases, starting at the end of this month, probably > with a shortish freeze for testing: is there anyone reading this who has > interest to perform any kind of dedicated testing at all (library > maintainers, application deployers) who would be able to systematically > test things before a release? > > I am also tempted to mess with the version number scheme, because I find > 1.0.x as x tends to infinity slightly odd -- but I recognize that there > may be practical reasons for not doing so: if anyone would be > inconvenienced by a change to 1.y or maybe even 2.y, please say so. > > Cheers, > > Christophe > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > |
From: Christophe R. <cs...@ca...> - 2012-09-03 15:31:26
|
Paul Nathan <pn...@va...> writes: > Not sure what you.quite mean by systematic testing- I'm assuming you > mean automated testing? Or perhaps some kind of well defined test > plan? Really what I mean is the well-defined test that gets carried out (ideally without fail, but we're all human) during the freeze period. The thing that I am trying to avoid is the pattern that I've observed previously where library/application maintainers test their software only after the release is made, leading to the somewhat frustrating sequence of a week's long development freeze, a release, and then an immediate bug report about a regression. So the more explicit testing that can happen during the freeze period, the better, and I'm trying to drum up support for that now :-) > Please let me know if this stuff would help. I think that having hardware coverage is very useful. Would you plan to run tests beyond building and our own regression tests on that? What software do you care about? :-) Cheers, Christophe |
From: Robert G. <rpg...@si...> - 2012-09-03 23:20:44
|
On 9/3/12 Sep 3 -6:31 AM, Christophe Rhodes wrote: > Hi, > > In the great tag game that is release management, I'm it for a while. I > plan to do monthly releases, starting at the end of this month, probably > with a shortish freeze for testing: is there anyone reading this who has > interest to perform any kind of dedicated testing at all (library > maintainers, application deployers) who would be able to systematically > test things before a release? What about seeing if something could be arranged with Anton Vodonosov to coordinate a run of the CL-TEST-GRID on a frozen build before release? cheers, r |
From: Daniel H. <dhe...@te...> - 2012-09-05 05:15:25
|
On Mon, 3 Sep 2012, Christophe Rhodes wrote: > I am also tempted to mess with the version number scheme, because I find > 1.0.x as x tends to infinity slightly odd On Mon, 3 Sep 2012, Paul Nathan wrote: > As a user, I find 1.0.n, n -> inf fairly odd. :) > > One scheme that is used and may be a good fit is 'Semantic Versioning' http://semver.org/. That looks like a fairly good scheme. It reminds me of libtool's scheme. The key goals of signalling changes that require code modification, changes that require recompilation, and changes that work transparently are similar. http://www.gnu.org/software/libtool/manual/html_node/Libtool-versioning.html http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html For SBCL, there are no ABI stability guarantees; so such schemes encode useless information. Every change requires a full recompilation. A calendar-based year.revision scheme avoids the monotony of meaningless revision numbers but also doesn't tell much about major updates. For SBCL, the following major.minor.micro scheme may make sense: (incf major) for significant Python/GC refactorization (incf minor) for large new feature sets, platforms, etc. or deprecating/removing external symbols (incf micro) for normal monthly releases or unplanned bugfix releases For example, the enhancements in sbcl-1.0.54 could have justified a minor bump instead of a micro. There is some difficulty in defining "proper" boundaries between the decimals. I tried guessing bounds where major means "big deal", minor means "wake up", and micro means "business as usual". Some day you might want to take a Slackware-inspired jump for pure marketing reasons; many people think "1.0" means "just out of beta", but SBCL is a bit more mature than that. Maybe a new versioning scheme could warrant a minor bump? - Daniel P.S. Where is the current SBCL versioning scheme documented? I seem to remember one, but a casual search didn't find the source. |
From: <me...@re...> - 2012-09-05 08:32:38
|
Daniel Herring <dhe...@te...> writes: > On Mon, 3 Sep 2012, Christophe Rhodes wrote: > >> I am also tempted to mess with the version number scheme, because I find >> 1.0.x as x tends to infinity slightly odd > > > On Mon, 3 Sep 2012, Paul Nathan wrote: > >> As a user, I find 1.0.n, n -> inf fairly odd. :) >> >> One scheme that is used and may be a good fit is 'Semantic Versioning' http://semver.org/. > > > That looks like a fairly good scheme. It reminds me of libtool's scheme. > The key goals of signalling changes that require code modification, > changes that require recompilation, and changes that work transparently > are similar. A long time ago, before git and its brothers came onto the scene and cvs was the default, I had the pleasure to implement some support for configuration management at a job. What came out of that effort was ho-cvs [1] based on meta-cvs, a really ugly workaround for not having a sane version control system. More importantly, coma [2] was born too. The idea was very similar to what semver describes, and we used it for versioning components of multiple products (and their slightly different variants). The solution was intended to help in reducing the merging overhead between all the different products by eliminating the need to create branches (only had to be considered for major (incompatible) changes), and be able to answer validate the current configuration by rules on versions and other configuration settings. One extension over semver is that versions support a 'variant', a branch name really. #v1.2.3 refers to version 1.2.3 on the main branch. #vX:4.5.6 refers to version 4.5.6 on branch X. The canonical representation of #vX:4.5.6 contain the branch off points back to the main root of the version tree like #v0.3.1/A:3.2.2/X:4.5.6. Two canonical versions can always be compared for compatibility. The code that implements this is version.lisp (and test-version.lisp) in the ho-cvs tarball [3]. My experience with tools relying on public API compatibility as specified by the programmer is that it's not black or white: adding a method to a java class is normally thought of as a minor (backwards compatible) change, but it could very well break subclasses or code that uses reflection. Also, most software has trouble defining a public API. Note that ho-cvs is obsolete and coma, while it has good ideas, is unmaintained. Gabor [1] http://quotenil.com/ho-cvs/ [2] http://quotenil.com/coma/ [3] http://quotenil.com/ho-cvs/download/hoc-0.1.4.tar.gz |
From: Nikodemus S. <nik...@ra...> - 2012-09-10 06:58:33
|
On 3 September 2012 14:31, Christophe Rhodes <cs...@ca...> wrote: > I am also tempted to mess with the version number scheme, because I find > 1.0.x as x tends to infinity slightly odd -- but I recognize that there > may be practical reasons for not doing so: if anyone would be > inconvenienced by a change to 1.y or maybe even 2.y, please say so. I'm all for this. Cheers, -- Nikodemus |