> > A question: How do you go about creating the 'beta release' that is > placed into the 'group file section'? Do you start with a fresh > 'snapshot' of the whole SVN trunk?
of course > If so, please add a SVN tag so we > know exactly what you started with. > Please explain why you want to use a tag ? Isn't just a revision number enough ? > > Then, I am proposing a testing/waiting period. Participation in the > testing is voluntary. You feel that 30 days is too long, so how about > 21 days? > Yes, no, why not, I don't know :) I think there's no definite number of day (maybe 42...), it depends on available people at that moment and release content itself. Also, and I insist, we're using continuous integration with buildbot, TORELEASE, weekly packages, unittests, etc... This is not a big-bang release, releasing in our case means stating few things (changelog, branch) and that's it, because the differences between a weekly packages and a final one are mininal. Again, please explain what you're testing during this "testing period". And what will occur if there's not enough volunteer ? How will you track what you've tested and what you haven't. With which jallib version ? With which compiler version ? With which PIC ? You should also search the group for "testing matrix" or things related to how to test jallib (hours of reading I guess). Also google for "good enough software"... AFAIC, I only trust automated tests, like unittests. Ideally, ultimately, we'd need some kind of functional compiler specifications we could write unittests against. That way you would be able to build a safety net, to test new compiler versions, and automated as least in PC-in-silico. I try to do this, see this unittest about new "alias" keyword: http://code.google.com/p/jallib/source/browse/trunk/test/unittest/jalv2_alias.jalt. It may someday detect a problem... or not. We'd need the same for some jallib libraries. I wrote a bunch of tests for ADC libs, and they occur to detect a problem in device files (and also fix a highly complex environment, with many, many variables). Finally, the fact is if there's a problem, we're able to fix it fast by tracking changes with SVN, and release a new version also fast, thanks to our continuous tools. Not every project can do this, that's also a safety net. > > Now then, when we get to the end of the 21 days, and assuming we want > to make this release 'official', the question comes up-- do we release > exactly the same files as the 'beta release', or do we get a new > snapshot from trunk, and generate a new SVN tag? > As I said, I used to create branch for beta, then another for final release. By experience, it occured it wasn't that necessary. Keep in mind that things don't move that much between beta and final. Particularly because we have TORELEASE file acting as a kind of buffer. Between beta and final, people can still commit new libraries/modications, if it doesn't hit TORELEASE, that's transparent. We need to be pragmatic. So far we haven't had any problems. I understand you want to add tag (I still have my doubts about how useful it is *in our case*), and specify a fixed number of days between beta and final (I have doubts too about a fixed number of day, I hope you understood we're already waiting days between beta and final). Is that right ? Anyway, not a big deal... Cheers, Seb -- You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
