I've been thinking... until UYOK replaces the stock kernel (which it may or may not do), it might be worth while to do releases of SystemImager with no feature changes except for updated kernel/drivers/modules. So perhaps the last revision number can be used for this purpose only and feature change can be signified by the minor version number.
Perhaps this causes more problem than it solves, but just an idea. Cheers, Bernard > -----Original Message----- > From: Brian Elliott Finley [mailto:[EMAIL PROTECTED] On > Behalf Of Brian Elliott Finley > Sent: Thursday, December 15, 2005 14:10 > To: Andrea Righi > Cc: Bernard Li; sisuite-devel@lists.sourceforge.net > Subject: Re: [Sisuite-devel] 3.5.4 release and version change > > Ok. > > I'll address the kernel source issue, then tag. Otherwise, let's > consider trunk frozen until after I tag. > > -Brian > > > > Thus spake Andrea Righi ([EMAIL PROTECTED]): > >Bernard Li wrote: > > > >>>>>I'm ready to do this. I expect to have udev support > ready very soon > >>>>>after the 3.5.4 release, but think we should release > 3.5.4 without it. > >> > >>> > >>> > >>> Like I said in the other email, I guess as long as we can > tag now and > >>> tag again later (with udev additions), then I'm okay with it. I'm > >>> really eager to have that featured included in one form > or another. > >>> > >>> Andrea, are you planning on checking anything else in? > We'd like to tag > >>> 3.5.4 to be included with OSCAR. My feeling is that > (time permitting) > >>> we will tag 3.5.5 with udev and reboot scripts and include that > >>> instead... > >>> > > > > > >I've not any other fix... in the last patch I've fixed an > ugly bug that > >forbade to use LVM in 64bit archs (or better in the cases when parted > >was used to gather partitioning info) and I think the > monitoring stuff > >seems to be stable, so at the moment I'm very happy to tag another > >release ASAP :-) > > > > > >>> > >> > >>>>>Because of the way svn does revision numbers, a revision > >>>>>number uniquely > >>>>>identifies a snapshot of the repository. Based on this, > I've been > >>>>>wondering if it would make sense to use the svn revision > number as the > >>>>>version number for future releases, and ditch the stable > vs. unstable > >>>>>bit. People have been using the unstable branch quite > happily, as if > >>>>>it were stable, for some time now. > >> > >>> > >>> > >>> Are you saying that we will no longer have version #s > like 3.x.x and > >>> just have SVN revision numbers? > >>> > > > > > >IMO the old versioning is nicer than SVN revision numbers... just > >because with the standard versioning we can better "highlight" the > >releases with minor fixes/improvements from the releases with major > >changes... but this is only a personal opinion... > > > >Cheers, > >-Andrea > > -- > Brian Elliott Finley > Mobile: 630.631.6621 > ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click _______________________________________________ Sisuite-devel mailing list Sisuite-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-devel
