Source Mage code commit list

[seth AT swoolley.homeip.net]

I suggest:

$VERSION-$PATCHLEVEL.$SECURITY_PATCH with empty vars sugar'd to zero.

I agree that demanding a patchlevel bump with a security_patch is more than 
needed.

Also (though I think this would simply add confusion) since both are 
monotonically
increasing, a sum of the two would also be monotonically increasing, so it 
could be
collapsed into one number for gaze display.  I think the v-p.s format is 
simple
enough.

Seth

On Wed, Aug 09, 2006 at 01:31:24PM +0300, Juuso Alasuutari wrote:
> I want to get back to this discussion. What is the common opinion about 
> updating PATCHLEVEL when SECURITY_PATCH is updated? If I've understood 
> correctly, when Ladislav says "we should update..." he isn't referring to a 
> standing policy, but suggesting a new one, no?
> 
> His concern is valid IMHO. Seeing more information with `gaze version` 
> would 
> be nice, perhaps even useful :). But I also think that demanding a 
> PATCHLEVEL 
> bump when SECURITY_PATCH is upgraded is too much. Such things are easy to 
> forget, and it's enough to have to remember to reset PATCHLEVEL on version 
> upgrades.
> 
> I suggest we shouldn't try to artificially bind these two, but rather 
> display 
> both with `gaze version` - or if it feels like too much info, add an option 
> to display the verbose version. For instance:
> 
> VERSION=1.2 PATCHLEVEL=3 SECURITY_PATCH=4 == 1.2-3:4
> 
> 
> On Thursday 03 August 2006 02:25, Ladislav Hagara wrote:
> [snip]
> > BTW, it could be fine if PATCHLEVEL was printed with gaze version (for
> > example firefox 1.5.0.6-2). I think it is something in devel sorcery to
> > print PATCHLEVEL but only with some special option. It could be printed
> > with normal gaze version. If user reports problem with firefox 1.5.0.6
> > we do not know what patches are applied, when (roughly) he/she cast it
> > and so on. If he/she reports problem with version 1.5.0.6-2 we get more
> > info. Moreover I would like to see these versions in our ledger. And for
> > example highlight versions with security problems.
> >
> > When we update SECURITY_PATCH we should update also PATCHLEVEL to see
> > the change in "gaze version".
> > Example:
> > VERSION=1.5.0.5 -> PATCHLEVEL=6 -> SECURITY_PATCH=4
> > Upgrade to new version: VERSION=1.5.0.6 -> PATCHLEVEL=0 (not removing
> > from DETAILS just set to 0) -> SECURITY_PATCH=4 (never reset)
> > Patch with new feature: VERSION=1.5.0.6 -> PATCHLEVEL=1 -> 
> > SECURITY_PATCH=4
> > Security fix: VERSION=1.5.0.6 -> PATCHLEVEL=2 -> SECURITY_PATCH=5
> > Patch with new feature: VERSION=1.5.0.6 -> PATCHLEVEL=3 -> 
> > SECURITY_PATCH=5
> > Upgrade to new version with security fix: VERSION=1.5.0.7 ->
> > PATCHLEVEL=0 -> SECURITY_PATCH=6
> > ...
> >
> > Just thinking how to bind SECURITY_PATCH=5 with PATCHLEVEL=2. Need to
> > know from VERSION-PATCHLEVEL if it is security fixed or no.
> > What about SECURITY_PATCH (or FIX)=5:1.5.0.6:2 ?
> > Just idea ...
> 
> -- 
>         Juuso Alasuutari
> [[ Source Mage GNU/Linux ]]



> _______________________________________________
> SM-Commit mailing list
> SM-Commit AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-commit