Well,
According to the DEVELOPER_GUIDELINES, the third digit indicates a
bug-fix release. So, if we're going from kernel 2.6.10 to 2.6.12, I
think it's reasonable to consider that a bug-fix release. If we're
going from 2.6.10 -> 2.7.x, then I'd probably save that for a feature
release.
Cheers, -Brian
Thus spake Bernard Li ([EMAIL PROTECTED]):
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
--
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
