> > > > Is there anything written down about JALLIB's release process and > concepts? This is a sincere question -- perhaps I've overlooked it. >
You already asked this: http://groups.google.com/group/jallib/msg/b983e6ac842cc2ea > > Another question - since I am relatively new to JALLIB, do we really > do 'branches', or, do we mostly do 'tags'? > When I created the release (and you sure have noticed I created a 0.1-beta branch at that time), I created a branch, as I always do when releasing. Clearly our branches more look like tags. In Jaluino, I use tags. tags or branches, at the end it's the same with SVN. > > A branch, implies that you would be maintaining (bug-fixes, etc) > multiple versions of JALLIB. Similar to Linux kernel -- there is a > 2.4.x series and a 2.6.x series, and both are still actively being > maintained. > That was the idea. > > A tag, seems to me, is more like what we do here-- once in a while, > we issue a 'release', and that is it, no bug fixes, until the next > 'release'. And no support for older 'releases' -- instead, everyone > must upgrade to the latest/current release. > When you modify a file in a tag, then it's a branch (strictly CVS speaking, and IIRC, you can't create a tag and modify files within that tag, like SVN). > > I will try to use the term 'tag' in the future. > To be consistent, release tags or branches or whatever should still remain in "branches", where all releases are. > > So, my suggestion for release process is: > > 1) tag a candidate release in Subversion > 2) test it for nnn days > 3) After nnn days, if less than yyy non-critical bugs reported, then > 4) release it. > > If 3) above fails, then we must start over at step 1. > This is what we already do, except tagging SVN, for which I have my doubts about how useful it is. Remember that since we don't keep all SVN content to build release content, we need to *actually* test the release packages. That's why I always upload beta packages in group file section. This is a very important point. What have I forgotten? > Thinking again about this "bad mistake", I guess this is about embedding a not fully tested compiler in jallib 0.5. You seem to have forgotten to explain how to decide if a compiler is fully tested or not. Do we have to wait several days ? How much ? Do we have to check if things are compiling fine ? Or do we have to also test if things are running in the real world ? Compiler betas are tested for several days here in jallib, in buildbot, but also in the real world. Rob has actively tested it I think. I think nobody can tell if the compiler is stable enough, maybe except Kyle. You can also write unittests (see wiki) to test several important aspects of the compiler. This is the kind of things I believe it can help, but it's time-consuming. Considering this, how "bad" was that "mistake" ?... 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.
