kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #00759
Re: Subversion Changes
-
To:
kicad-devel@xxxxxxxxxxxxxxx
-
From:
Renaud Helias <renaud.helias@...>
-
Date:
Fri, 23 Nov 2007 08:10:59 +0100
-
In-reply-to:
<47465BE1.4020200@...>
--Apple-Mail-4-598811206 Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=ISO-8859-1;
delsp=yes;
format=flowed
Just think about future, what happen when you remove the tag (or move=20=20
it, or svn complete mirror)
It is great to find back it svn number, so that a dead link on a blog=20=20
can be rescue.
Newbies (like me) more the time use the name of what they used while=20=20
download (the tagname in this cause) to name it try of binary without=20=20
any documentation...
I vote for kicad-2007-Nov_470 :p
A Frenchy Boy.
Le 23 nov. 07 =E0 05:49, Dick Hollenbeck a =E9crit :
> David Bourgeois wrote:
> > On Thu, 22 Nov 2007 18:19:06 +0100, Igor Plyatov=20=20
> <plyatov@...> wrote:
> >
> >
> >> Hello Dick!
> >>
> >>> 1) The November release candidate has been copied into
> >>> *https://kicad.svn.sourceforge.net/svnroot/kicad/tags/=20
> kicad-2007-Nov*
> >>>
> >>> Notice that the day of month has been dropped and we are using=20=20
> 'Nov'
> >>> instead of 11.
> >>>
> >>>
> >> Who is this "we"? ;-)
> >> Such enumeration of versions is undesirable for example in my=20=20
> Gentoo
> >> Linux.
> >> It is impossible to correctly compare such versions at package=20=20
> upgrade.
> >> The examples of good version numbering:
> >> 1.4
> >> 1.4.2
> >> 1.4-r2 (2 - is a release of package)
> >> 200711
> >> 20071122
> >> 200711-r468 (468 - is a SVN revision)
> >> 20071122-r468 (468 - is a SVN revision)
> >> r468
> >>
> >> Can we come to the consensus with KiCad versioning?
> >>
> >> My propositions of numbering:
> >> 200711
> >> 20071122
> >> or maybe 2.0
> >>
> >> P.S. This is not a criticism, but a requirement for some=20=20
> compatibility.
> >>
> >
> > Hi Dick and Igor,
> >
> > (Just my 2 cents.) I thought that tags were not meant to be=20=20
> changed at all
> > as they represent a frozen release. In my understanding, I was=20=20
> expecting a
> > tag (for the current release) and a branch for future bug fixes. The
> > branch can be named kicad-2007-Nov or whatever but the tag should=20=20
> better
> > be a number (friendlyness with most package managers). I'd=20=20
> personnaly vote
> > for '20071122' as that's how past releases were done already.
> >
> > Cheers,
> > David Bourgeois
> >
>
> The subversion architecture is pretty flexible. How we lay out the
> tree is by convention, and convention is what we make it. The=20=20
> subtree I
> created is meant to be "stable", and possibly frozen. In practice,
> software that is frozen is software that keeps its bugs.
>
> The difference between frozen and stable is a function of how many=20=20
> bugs
> people want to fix. If you want it frozen, then don't change anything
> in that subtree. My expectations are that this new subtree would get 2
> to 10 bug fixes max before that subtree dies out and people switch=20=20
> back
> to trunk a month or two from now. I don't really understand all the
> commotion.
>
> As to the remark about "branch" vs "tags", I saw no purpose in having
> both of them for a release or a release candidate. A branch tree would
> be useful for temporary "out of trunk" work, which eventually gets
> merged and then deleted. This Nov-2007 release is no such thing. With
> too many subtrees, it would mean that changes may need to be merged or
> copied across to each one, causing more work. There are not enough
> man-hours donated here as it is.
>
> As for version numbering, IMO we have that in the svn mechanism. If=20=20
> you
> want to describe a particular version, you can always do so as=20=20
> follows:
>
> https://kicad.svn.sourceforge.net/svnroot/kicad/tags/kicad-2007-=20
> Nov@470
>
> notice that @470, this is the subversion version number, and there can
> be a small handful of them in the kicad-2007-Nov subtree.
>
> or
>
> svn switch
> https://kicad.svn.sourceforge.net/svnroot/kicad/tags/kicad-2007-=20
> Nov@470
>
> Within the kicad-2007-Nov subtree, there will not be a lot of separate
> versions, at most two months worth, maybe 2 to 10 bug fixes. If you
> like a particular version other than the most recent found within the
> subtree (which presumably would have the largest number of bugs=20=20
> fixed),
> then remember the subversion version number for it and tell your=20=20
> friends
> about that so they can check it out.
>
> Nothing I have heard in the most recent postings persuade me to=20=20
> believe
> that we are going down anything but the best path. But I am still
> listening if you care to elaborate your point of view and describe a
> particular example scenario that we cannot address easily in the next
> two months or at any other time.
>
> Also, remember that the "release candidate" becomes a "release" when
> binaries are made and put out for folks who don't build it themselves.
> The exact date of that is not known until it happens, when bugs slow
> down. And here's the important driver: in the mean time work needs
> to happen on the NEXT release, namely the improved zone support. So=20=20
> the
> November release had to be put some place "stable".
>
> The binaries can have any name or version number that folks want to=20=20
> give
> them. That is what most users get. Somebody can document on this list
> or in the readme file, an association between the binary version=20=20
> number
> used, and the subversion version number within the kicad-2007-Nov=20=20
> tree,
> at the time the binaries are released, and then anybody can rebuild=20=20
> that
> binary exactly any time in the future.
>
> Again, I think what we have is good, it works for me anyway.
>
> Dick Hollenbeck
> SoftPLC Corporation
> http://softplc.com
>
>
>=20
--Apple-Mail-4-598811206 Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=ISO-8859-1
<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webk=
it-line-break: after-white-space; ">
<div>Just think about future, what happen when you remove the tag (or move =
it, or svn complete mirror)</div><div><br class=3D"webkit-block-placeholder=
"></div><div>It is great to find back it svn number, so that a dead link on=
a blog can be rescue.</div><div><br class=3D"webkit-block-placeholder"></d=
iv><div>Newbies (like me) more the time use the name of what they used whil=
e download (the tagname in this cause) to name it try of binary without any=
documentation...</div><div><br class=3D"webkit-block-placeholder"></div><d=
iv>I vote for=A0<span class=3D"Apple-style-span" style=3D"font-family: Geor=
gia; font-size: 13px; line-height: 15px; ">=A0kicad-2007-Nov_470 :p</span><=
/div><div><br></div><div>A Frenchy Boy.</div><div><br class=3D"webkit-block=
-placeholder"></div><br><div><div>Le 23 nov. 07 =E0 05:49, Dick Hollenbeck =
a =E9crit :</div><br class=3D"Apple-interchange-newline"><blockquote type=
=3D"cite"><span class=3D"Apple-style-span" style=3D"border-collapse: separa=
te; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-styl=
e: normal; font-variant: normal; font-weight: normal; letter-spacing: norma=
l; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; tex=
t-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webk=
it-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -w=
ebkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -we=
bkit-text-stroke-width: 0; "><div id=3D"ygrp-mlmsg" style=3D"width: 655px; =
position: relative; font-size: 13px; font-family: arial, helvetica, clean, =
sans-serif; "><div id=3D"ygrp-msg" style=3D"width: 490px; padding-top: 0px;=
padding-right: 15px; padding-bottom: 0px; padding-left: 0px; float: left; =
z-index: 1; line-height: 1.22em; "><div id=3D"ygrp-text" style=3D"line-heig=
ht: 1.22em; font-family: Georgia; "><p style=3D"line-height: 1.22em; margin=
-top: 0px; margin-right: 0px; margin-bottom: 1em; margin-left: 0px; ">David=
Bourgeois wrote:<br style=3D"line-height: 1.22em; ">> On Thu, 22 Nov 20=
07 18:19:06 +0100, Igor Plyatov <<a href=3D"mailto:plyatov%40mail.ru"; st=
yle=3D"line-height: 1.22em; ">plyatov@mail.<wbr style=3D"line-height: 1.22e=
m; ">ru</a>> wrote:<br style=3D"line-height: 1.22em; ">><br style=3D"=
line-height: 1.22em; ">><span class=3D"Apple-converted-space">=A0</span>=
<br style=3D"line-height: 1.22em; ">>> Hello Dick!<br style=3D"line-h=
eight: 1.22em; ">>><span class=3D"Apple-converted-space">=A0</span><b=
r style=3D"line-height: 1.22em; ">>>> 1) The November release cand=
idate has been copied into<br style=3D"line-height: 1.22em; ">>>> =
*<a href=3D"https://kicad.svn.sourceforge.net/svnroot/kicad/tags/kicad-2007=
-Nov*" style=3D"line-height: 1.22em; ">https://kicad.<wbr style=3D"line-hei=
ght: 1.22em; ">svn.sourceforge.<wbr style=3D"line-height: 1.22em; ">net/svn=
root/<wbr style=3D"line-height: 1.22em; ">kicad/tags/<wbr style=3D"line-hei=
ght: 1.22em; ">kicad-2007-<wbr style=3D"line-height: 1.22em; ">Nov*</a><br =
style=3D"line-height: 1.22em; ">>>><br style=3D"line-height: 1.22e=
m; ">>>> Notice that the day of month has been dropped and we are =
using 'Nov'<br style=3D"line-height: 1.22em; ">>>> instead of 11.<=
br style=3D"line-height: 1.22em; ">>>><br style=3D"line-height: 1.=
22em; ">>>><span class=3D"Apple-converted-space">=A0</span><br sty=
le=3D"line-height: 1.22em; ">>> Who is this "we"? ;-)<br style=3D"lin=
e-height: 1.22em; ">>> Such enumeration of versions is undesirable fo=
r example in my Gentoo<span class=3D"Apple-converted-space">=A0</span><br s=
tyle=3D"line-height: 1.22em; ">>> Linux.<br style=3D"line-height: 1.2=
2em; ">>> It is impossible to correctly compare such versions at pack=
age upgrade.<br style=3D"line-height: 1.22em; ">>> The examples of go=
od version numbering:<br style=3D"line-height: 1.22em; ">>> 1.4<br st=
yle=3D"line-height: 1.22em; ">>> 1.4.2<br style=3D"line-height: 1.22e=
m; ">>> 1.4-r2 (2 - is a release of package)<br style=3D"line-height:=
1.22em; ">>> 200711<br style=3D"line-height: 1.22em; ">>> 2007=
1122<br style=3D"line-height: 1.22em; ">>> 200711-r468 (468 - is a SV=
N revision)<br style=3D"line-height: 1.22em; ">>> 20071122-r468 (468 =
- is a SVN revision)<br style=3D"line-height: 1.22em; ">>> r468<br st=
yle=3D"line-height: 1.22em; ">>><br style=3D"line-height: 1.22em; ">&=
gt;> Can we come to the consensus with KiCad versioning?<br style=3D"lin=
e-height: 1.22em; ">>><br style=3D"line-height: 1.22em; ">>> My=
propositions of numbering:<br style=3D"line-height: 1.22em; ">>> 200=
711<br style=3D"line-height: 1.22em; ">>> 20071122<br style=3D"line-h=
eight: 1.22em; ">>> or maybe 2.0<br style=3D"line-height: 1.22em; ">&=
gt;><br style=3D"line-height: 1.22em; ">>> P.S. This is not a crit=
icism, but a requirement for some compatibility.<br style=3D"line-height: 1=
.22em; ">>><span class=3D"Apple-converted-space">=A0</span><br style=
=3D"line-height: 1.22em; ">><br style=3D"line-height: 1.22em; ">> Hi =
Dick and Igor,<br style=3D"line-height: 1.22em; ">><br style=3D"line-hei=
ght: 1.22em; ">> (Just my 2 cents.) I thought that tags were not meant t=
o be changed at all<span class=3D"Apple-converted-space">=A0</span><br styl=
e=3D"line-height: 1.22em; ">> as they represent a frozen release. In my =
understanding, I was expecting a<span class=3D"Apple-converted-space">=A0</=
span><br style=3D"line-height: 1.22em; ">> tag (for the current release)=
and a branch for future bug fixes. The<span class=3D"Apple-converted-space=
">=A0</span><br style=3D"line-height: 1.22em; ">> branch can be named ki=
cad-2007-Nov or whatever but the tag should better<span class=3D"Apple-conv=
erted-space">=A0</span><br style=3D"line-height: 1.22em; ">> be a number=
(friendlyness with most package managers). I'd personnaly vote<span class=
=3D"Apple-converted-space">=A0</span><br style=3D"line-height: 1.22em; ">&g=
t; for '20071122' as that's how past releases were done already.<br style=
=3D"line-height: 1.22em; ">><br style=3D"line-height: 1.22em; ">> Che=
ers,<br style=3D"line-height: 1.22em; ">> David Bourgeois<br style=3D"li=
ne-height: 1.22em; ">><span class=3D"Apple-converted-space">=A0</span><b=
r style=3D"line-height: 1.22em; "><br style=3D"line-height: 1.22em; ">The s=
ubversion architecture is pretty flexible. How we lay out the<span class=3D=
"Apple-converted-space">=A0</span><br style=3D"line-height: 1.22em; ">tree =
is by convention, and convention is what we make it. The subtree I<span cla=
ss=3D"Apple-converted-space">=A0</span><br style=3D"line-height: 1.22em; ">=
created is meant to be "stable", and possibly frozen. In practice,<span cla=
ss=3D"Apple-converted-space">=A0</span><br style=3D"line-height: 1.22em; ">=
software that is frozen is software that keeps its bugs.<br style=3D"line-h=
eight: 1.22em; "><br style=3D"line-height: 1.22em; ">The difference between=
frozen and stable is a function of how many bugs<span class=3D"Apple-conve=
rted-space">=A0</span><br style=3D"line-height: 1.22em; ">people want to fi=
x. If you want it frozen, then don't change anything<span class=3D"Apple-co=
nverted-space">=A0</span><br style=3D"line-height: 1.22em; ">in that subtre=
e. My expectations are that this new subtree would get 2<span class=3D"Appl=
e-converted-space">=A0</span><br style=3D"line-height: 1.22em; ">to 10 bug =
fixes max before that subtree dies out and people switch back<span class=3D=
"Apple-converted-space">=A0</span><br style=3D"line-height: 1.22em; ">to tr=
unk a month or two from now. I don't really understand all the<span class=
=3D"Apple-converted-space">=A0</span><br style=3D"line-height: 1.22em; ">co=
mmotion.<br style=3D"line-height: 1.22em; "><br style=3D"line-height: 1.22e=
m; ">As to the remark about "branch" vs "tags", I saw no purpose in having<=
span class=3D"Apple-converted-space">=A0</span><br style=3D"line-height: 1.=
22em; ">both of them for a release or a release candidate. A branch tree wo=
uld<span class=3D"Apple-converted-space">=A0</span><br style=3D"line-height=
: 1.22em; ">be useful for temporary "out of trunk" work, which eventually g=
ets<span class=3D"Apple-converted-space">=A0</span><br style=3D"line-height=
: 1.22em; ">merged and then deleted. This Nov-2007 release is no such thing=
. With<span class=3D"Apple-converted-space">=A0</span><br style=3D"line-hei=
ght: 1.22em; ">too many subtrees, it would mean that changes may need to be=
merged or<span class=3D"Apple-converted-space">=A0</span><br style=3D"line=
-height: 1.22em; ">copied across to each one, causing more work. There are =
not enough<span class=3D"Apple-converted-space">=A0</span><br style=3D"line=
-height: 1.22em; ">man-hours donated here as it is.<span class=3D"Apple-con=
verted-space">=A0</span><br style=3D"line-height: 1.22em; "><br style=3D"li=
ne-height: 1.22em; ">As for version numbering, IMO we have that in the svn =
mechanism. If you<span class=3D"Apple-converted-space">=A0</span><br style=
=3D"line-height: 1.22em; ">want to describe a particular version, you can a=
lways do so as follows:<br style=3D"line-height: 1.22em; "><br style=3D"lin=
e-height: 1.22em; "><a href=3D"https://kicad.svn.sourceforge.net/svnroot/ki=
cad/tags/kicad-2007-Nov@470" style=3D"line-height: 1.22em; ">https://kicad.=
<wbr style=3D"line-height: 1.22em; ">svn.sourceforge.<wbr style=3D"line-hei=
ght: 1.22em; ">net/svnroot/<wbr style=3D"line-height: 1.22em; ">kicad/tags/=
<wbr style=3D"line-height: 1.22em; ">kicad-2007-<wbr style=3D"line-height: =
1.22em; ">Nov@470</a><br style=3D"line-height: 1.22em; "><br style=3D"line-=
height: 1.22em; ">notice that @470, this is the subversion version number, =
and there can<span class=3D"Apple-converted-space">=A0</span><br style=3D"l=
ine-height: 1.22em; ">be a small handful of them in the kicad-2007-Nov subt=
ree.<br style=3D"line-height: 1.22em; "><br style=3D"line-height: 1.22em; "=
>or<br style=3D"line-height: 1.22em; "><br style=3D"line-height: 1.22em; ">=
svn switch<span class=3D"Apple-converted-space">=A0</span><br style=3D"line=
-height: 1.22em; "><a href=3D"https://kicad.svn.sourceforge.net/svnroot/kic=
ad/tags/kicad-2007-Nov@470" style=3D"line-height: 1.22em; ">https://kicad.<=
wbr style=3D"line-height: 1.22em; ">svn.sourceforge.<wbr style=3D"line-heig=
ht: 1.22em; ">net/svnroot/<wbr style=3D"line-height: 1.22em; ">kicad/tags/<=
wbr style=3D"line-height: 1.22em; ">kicad-2007-<wbr style=3D"line-height: 1=
.22em; ">Nov@470</a><br style=3D"line-height: 1.22em; "><br style=3D"line-h=
eight: 1.22em; ">Within the kicad-2007-Nov subtree, there will not be a lot=
of separate<span class=3D"Apple-converted-space">=A0</span><br style=3D"li=
ne-height: 1.22em; ">versions, at most two months worth, maybe 2 to 10 bug =
fixes. If you<span class=3D"Apple-converted-space">=A0</span><br style=3D"l=
ine-height: 1.22em; ">like a particular version other than the most recent =
found within the<span class=3D"Apple-converted-space">=A0</span><br style=
=3D"line-height: 1.22em; ">subtree (which presumably would have the largest=
number of bugs fixed),<span class=3D"Apple-converted-space">=A0</span><br =
style=3D"line-height: 1.22em; ">then remember the subversion version number=
for it and tell your friends<span class=3D"Apple-converted-space">=A0</spa=
n><br style=3D"line-height: 1.22em; ">about that so they can check it out.<=
br style=3D"line-height: 1.22em; "><br style=3D"line-height: 1.22em; ">Noth=
ing I have heard in the most recent postings persuade me to believe<span cl=
ass=3D"Apple-converted-space">=A0</span><br style=3D"line-height: 1.22em; "=
>that we are going down anything but the best path. But I am still<span cla=
ss=3D"Apple-converted-space">=A0</span><br style=3D"line-height: 1.22em; ">=
listening if you care to elaborate your point of view and describe a<span c=
lass=3D"Apple-converted-space">=A0</span><br style=3D"line-height: 1.22em; =
">particular example scenario that we cannot address easily in the next<spa=
n class=3D"Apple-converted-space">=A0</span><br style=3D"line-height: 1.22e=
m; ">two months or at any other time.<br style=3D"line-height: 1.22em; "><b=
r style=3D"line-height: 1.22em; ">Also, remember that the "release candidat=
e" becomes a "release" when<span class=3D"Apple-converted-space">=A0</span>=
<br style=3D"line-height: 1.22em; ">binaries are made and put out for folks=
who don't build it themselves.<span class=3D"Apple-converted-space">=A0</s=
pan><br style=3D"line-height: 1.22em; ">The exact date of that is not known=
until it happens, when bugs slow<span class=3D"Apple-converted-space">=A0<=
/span><br style=3D"line-height: 1.22em; ">down. And here's the important dr=
iver: in the mean time work needs<span class=3D"Apple-converted-space">=A0<=
/span><br style=3D"line-height: 1.22em; ">to happen on the NEXT release, na=
mely the improved zone support. So the<span class=3D"Apple-converted-space"=
>=A0</span><br style=3D"line-height: 1.22em; ">November release had to be p=
ut some place "stable".<span class=3D"Apple-converted-space">=A0</span><br =
style=3D"line-height: 1.22em; "><br style=3D"line-height: 1.22em; ">The bin=
aries can have any name or version number that folks want to give<span clas=
s=3D"Apple-converted-space">=A0</span><br style=3D"line-height: 1.22em; ">t=
hem. That is what most users get. Somebody can document on this list<span c=
lass=3D"Apple-converted-space">=A0</span><br style=3D"line-height: 1.22em; =
">or in the readme file, an association between the binary version number<s=
pan class=3D"Apple-converted-space">=A0</span><br style=3D"line-height: 1.2=
2em; ">used, and the subversion version number within the kicad-2007-Nov tr=
ee,<span class=3D"Apple-converted-space">=A0</span><br style=3D"line-height=
: 1.22em; ">at the time the binaries are released, and then anybody can reb=
uild that<span class=3D"Apple-converted-space">=A0</span><br style=3D"line-=
height: 1.22em; ">binary exactly any time in the future.<br style=3D"line-h=
eight: 1.22em; "><br style=3D"line-height: 1.22em; ">Again, I think what we=
have is good, it works for me anyway.<br style=3D"line-height: 1.22em; "><=
br style=3D"line-height: 1.22em; ">Dick Hollenbeck<br style=3D"line-height:=
1.22em; ">SoftPLC Corporation<br style=3D"line-height: 1.22em; "><a href=
=3D"http://softplc.com"; style=3D"line-height: 1.22em; ">http://softplc.<wbr=
style=3D"line-height: 1.22em; ">com</a><br style=3D"line-height: 1.22em; "=
><br style=3D"line-height: 1.22em; "></p></div><span width=3D"1" style=3D"c=
olor: white; line-height: 1.22em; "></span></span></blockquote></div><br></=
body></html> --Apple-Mail-4-598811206--
Follow ups
References
