versioning

versioning

[Karel Zak]

 Hi,

 Sami has good point on IRC... do we really want to continue with the
 current versioning schema? Now we use:

    v2.xx[.y]

 I don't expect v3 or v4, so the prefix v2 does not provide any
 information... and the 'xx' ('30' now) is already large number. 

 Suggestions:

 1) do nothing; nobody cares and v2.31 looks good

 2) remove '2' from the version:

        major release:  v31
        update release: v31.1


 3) <your suggestion>?
 

 Note that for v2.30 is to late to do any change in version numbers
 (we need changes in our libraries and I have to update some my scripts).

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: versioning

[Ruediger Meier]

On Wednesday 17 May 2017, Karel Zak wrote:
>  Hi,
>
>  Sami has good point on IRC... do we really want to continue with the
>  current versioning schema? Now we use:
>
>     v2.xx[.y]
>
>  I don't expect v3 or v4, so the prefix v2 does not provide any
>  information... and the 'xx' ('30' now) is already large number.
>
>  Suggestions:
>
>  1) do nothing; nobody cares and v2.31 looks good
>
>  2) remove '2' from the version:
>
>         major release:  v31
>         update release: v31.1

I don't see why v31 would be better than v3? I always appreciate if 
there are no gaps in version numbers. So v31 should be released after 
v30 ;)

>
>  3) <your suggestion>?
>

I would prefer either v2.31 or v3.1.

v3 just to avoid big numbers. But could also be a hint regarding the 
minimum supported/tested kernel version. I believe that we have already 
a few incompatibilities for kernel <2.6.32. Maybe we could cleanup our 
code, only supporting kernel >=3.1.

cu,
Rudi

>  Note that for v2.30 is to late to do any change in version numbers
>  (we need changes in our libraries and I have to update some my
> scripts).
>
>     Karel

Re: versioning

[Ruediger Meier]

On Wednesday 17 May 2017, Ruediger Meier wrote:
> On Wednesday 17 May 2017, Karel Zak wrote:
> >  Hi,
> >
> >  Sami has good point on IRC... do we really want to continue with
> > the current versioning schema? Now we use:
> >
> >     v2.xx[.y]
> >
> >  I don't expect v3 or v4, so the prefix v2 does not provide any
> >  information... and the 'xx' ('30' now) is already large number.
> >
> >  Suggestions:
> >
> >  1) do nothing; nobody cares and v2.31 looks good
> >
> >  2) remove '2' from the version:
> >
> >         major release:  v31
> >         update release: v31.1
>
> I don't see why v31 would be better than v3? I always appreciate if
> there are no gaps in version numbers. So v31 should be released after
> v30 ;)
>
> >  3) <your suggestion>?
>
> I would prefer either v2.31 or v3.1.
>
> v3 just to avoid big numbers. But could also be a hint regarding the
> minimum supported/tested kernel version. I believe that we have
> already a few incompatibilities for kernel <2.6.32. Maybe we could
> cleanup our code, only supporting kernel >=3.1.

Note we could still continue with 2 digit version numbers as well 
without jumping to v31:

v2.30
v2.30.1
v2.30.2
v3.0
v3.1
v3.2
v4.0
[...]

> cu,
> Rudi
>
> >  Note that for v2.30 is to late to do any change in version numbers
> >  (we need changes in our libraries and I have to update some my
> > scripts).
> >
> >     Karel
>
> --
> To unsubscribe from this list: send the line "unsubscribe util-linux"
> in the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: versioning

[Bernhard Voelker]

On 05/17/2017 10:47 AM, Ruediger Meier wrote:
> v2.30
> v2.30.1
> v2.30.2
> v3.0
> v3.1
> v3.2

+1 to all your arguments - v31 and v31.1 look really odd.

Have a nice day,
Berny

Re: versioning

[Karel Zak]

On Wed, May 17, 2017 at 03:23:11PM +0200, Bernhard Voelker wrote:
> On 05/17/2017 10:47 AM, Ruediger Meier wrote:
> > v2.30
> > v2.30.1
> > v2.30.2
> > v3.0
> > v3.1
> > v3.2
> 
> +1 to all your arguments - v31 and v31.1 look really odd.

Well, the idea behind v31 is to make difference between the current
schema and the new one. The version number v3.1 maybe interpreted as a
new major release that is incompatible with v2.

Anyway, I have no strong opinion about it. It's just number :-) I can
live with v3.1 too.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: versioning

[Karel Zak]

On Wed, May 17, 2017 at 10:42:53AM +0200, Ruediger Meier wrote:
> v3 just to avoid big numbers. But could also be a hint regarding the 
> minimum supported/tested kernel version. I believe that we have already 
> a few incompatibilities for kernel <2.6.32. Maybe we could cleanup our 
> code, only supporting kernel >=3.1.

I'm almost sure we have users who use util-linux on old kernels. For
example RHEL6 with 2.6.32 is pretty common and I have no problem to
compile util-linux there. And sometimes we also backport patches from
util-linux upstream to RHEL6 etc ;-)

It's fine to kill things for 2.2 (etc.) but for I'd like to be
friendly to 2.6 users (if possible).

    Karel


./lscpu --version
lt-lscpu from util-linux 2.30-rc1-25-b7eb

$ ./lscpu
Architecture:        s390x
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Big Endian
CPU(s):              4
On-line CPU(s) list: 0-3
Thread(s) per core:  1
Core(s) per socket:  1
Socket(s) per book:  1
Book(s):             4
Vendor ID:           IBM/S390
Machine type:        2827
BogoMIPS:            2913.00
Hypervisor vendor:   (null)
Virtualization type: full
Dispatching mode:    horizontal
Flags:               esan3 zarch stfle msa ldisp eimm dfp etf3eh highgprs

$ uname -a
Linux devel2.s390.bos.redhat.com 2.6.32-550.el6.s390x #1 SMP Fri Apr 3 10:12:50 EDT 2015 s390x s390x s390x GNU/Linux


-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: versioning

[Ruediger Meier]

On Wednesday 17 May 2017, Karel Zak wrote:
> On Wed, May 17, 2017 at 10:42:53AM +0200, Ruediger Meier wrote:
> > v3 just to avoid big numbers. But could also be a hint regarding
> > the minimum supported/tested kernel version. I believe that we have
> > already a few incompatibilities for kernel <2.6.32. Maybe we could
> > cleanup our code, only supporting kernel >=3.1.
>
> I'm almost sure we have users who use util-linux on old kernels. For
> example RHEL6 with 2.6.32 is pretty common and I have no problem to
> compile util-linux there. And sometimes we also backport patches from
> util-linux upstream to RHEL6 etc ;-)

Hehe, I think 2.6.32 LTS is a very good lower boundary and it's almost 
kernel v3. ;) This version was released in 2009 and widely used (SLE, 
RHEL, Xen and many devices, routers, etc.).

I remember 73f4f3d9 where I fixed a 3 year old bug in ipcs. Probably 
nobody noticed this. So I don't think that anbody is really using 
recent ul on even older kernels.

> It's fine to kill things for 2.2 (etc.) but for I'd like to be
> friendly to 2.6 users (if possible).

We could remove <=2.4 hacks from our code, if any. Especially such very 
old history in the man pages, like tunelp.8:

"... the -T option on a 2.0.36 kernel with an tunelp compiled under 
2.1.131 or later may have unexpected effects."


cu,
Rudi

>     Karel
>
>
> ./lscpu --version
> lt-lscpu from util-linux 2.30-rc1-25-b7eb
>
> $ ./lscpu
> Architecture:        s390x
> CPU op-mode(s):      32-bit, 64-bit
> Byte Order:          Big Endian
> CPU(s):              4
> On-line CPU(s) list: 0-3
> Thread(s) per core:  1
> Core(s) per socket:  1
> Socket(s) per book:  1
> Book(s):             4
> Vendor ID:           IBM/S390
> Machine type:        2827
> BogoMIPS:            2913.00
> Hypervisor vendor:   (null)
> Virtualization type: full
> Dispatching mode:    horizontal
> Flags:               esan3 zarch stfle msa ldisp eimm dfp etf3eh
> highgprs
>
> $ uname -a
> Linux devel2.s390.bos.redhat.com 2.6.32-550.el6.s390x #1 SMP Fri Apr
> 3 10:12:50 EDT 2015 s390x s390x s390x GNU/Linux

Re: versioning

[Bruce Dubbs]

Karel Zak wrote:
>
>   Hi,
>
>   Sami has good point on IRC... do we really want to continue with the
>   current versioning schema? Now we use:
>
>      v2.xx[.y]
>
>   I don't expect v3 or v4, so the prefix v2 does not provide any
>   information... and the 'xx' ('30' now) is already large number.
>
>   Suggestions:
>
>   1) do nothing; nobody cares and v2.31 looks good
>
>   2) remove '2' from the version:
>
>          major release:  v31
>          update release: v31.1
>
>
>   3) <your suggestion>?

In managing about 1000 packages, I see a lot of different version 
numbering.   The vast majority of packages use (my terminology) 
major.minor.point for numbering.  The major number really should only be 
increased when there are incompatibilities introduced in a package update.

Sometimes the numbering gets large,  For instance the current lvm2 package 
number is 2.02.171.  But that is OK.  It tells us that the packages is 
updated frequently, but there is an effort to maintain backward compatibility.

When a package like firefox is at 53.0.2, what does that tell us about the 
changes?

Sometimes the numbering is downright silly.  I'll suggest that chromium at 
58.0.3029.96 falls into that category.

To give you an idea of what other packages use, take a look at 
http://wiki.linuxfromscratch.org/blfs/browser/trunk/BOOK/packages.ent

The bottom line is that from our point of view, x.y.z works fine.  There 
is no need to change the current numbering scheme.

   -- Bruce Dubbs
      linuxfromscratch.org

Re: versioning

[J William Piggott]

On 05/17/2017 03:47 AM, Karel Zak wrote:
> 
>  Hi,
> 
>  Sami has good point on IRC... do we really want to continue with the
>  current versioning schema? Now we use:
> 
>     v2.xx[.y]
> 
>  I don't expect v3 or v4, so the prefix v2 does not provide any
>  information... and the 'xx' ('30' now) is already large number. 
> 
>  Suggestions:
> 
>  1) do nothing; nobody cares and v2.31 looks good

I'd vote for number one.

> 
>  2) remove '2' from the version:
> 
>         major release:  v31
>         update release: v31.1
> 
> 
>  3) <your suggestion>?
>  
> 
>  Note that for v2.30 is to late to do any change in version numbers
>  (we need changes in our libraries and I have to update some my scripts).
> 
>     Karel
> 

Re: versioning

[Ruediger Meier]

On Wednesday 17 May 2017, Bruce Dubbs wrote:
> Karel Zak wrote:
> >   Hi,
> >
> >   Sami has good point on IRC... do we really want to continue with
> > the current versioning schema? Now we use:
> >
> >      v2.xx[.y]
> >
> >   I don't expect v3 or v4, so the prefix v2 does not provide any
> >   information... and the 'xx' ('30' now) is already large number.
> >
> >   Suggestions:
> >
> >   1) do nothing; nobody cares and v2.31 looks good
> >
> >   2) remove '2' from the version:
> >
> >          major release:  v31
> >          update release: v31.1
> >
> >
> >   3) <your suggestion>?
>
> In managing about 1000 packages, I see a lot of different version
> numbering.   The vast majority of packages use (my terminology)
> major.minor.point for numbering. 

> The major number really should only 
> be increased when there are incompatibilities introduced in a package
> update.

I agree, so I'd also vote for keeping the current version scheme. But we 
could talk about some (theoretically) incompatible clean-up changes to 
justify v3.1.

I'm not talking about making things incompatible just to be incompatible 
but about ugly, outdated ifdefs which probably nobody needs anymore but 
also nobody would touch unless we actively review this.

One thing already mentioned in this thread was to drop any code and 
documention regarding kernel < 2.6  (maybe even <2.6.32 if it has any 
benefits).

Maybe others have even more ideas, e.g. officially requiring 
POSIX.1-2008  or newer to cleanup include/c.h, configure.ac, etc..

The benfit would be not only to have a smaller minor version but 
hopefully to get a few well defined requirements for UL in 
Documentation/ directory, which will not change until v4. 

cu,
Rudi

> Sometimes the numbering gets large,  For instance the current lvm2
> package number is 2.02.171.  But that is OK.  It tells us that the
> packages is updated frequently, but there is an effort to maintain
> backward compatibility.
>
> When a package like firefox is at 53.0.2, what does that tell us
> about the changes?
>
> Sometimes the numbering is downright silly.  I'll suggest that
> chromium at 58.0.3029.96 falls into that category.
>
> To give you an idea of what other packages use, take a look at
> http://wiki.linuxfromscratch.org/blfs/browser/trunk/BOOK/packages.ent
>
> The bottom line is that from our point of view, x.y.z works fine. 
> There is no need to change the current numbering scheme.
>
>    -- Bruce Dubbs
>       linuxfromscratch.org
> --
> To unsubscribe from this list: send the line "unsubscribe util-linux"
> in the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: versioning

[Karel Zak]

On Wed, May 17, 2017 at 09:07:49PM +0200, Ruediger Meier wrote:
> I'm not talking about making things incompatible just to be incompatible 
> but about ugly, outdated ifdefs which probably nobody needs anymore but 
> also nobody would touch unless we actively review this.

This would be better to discuss per patch. I don't think the current
code is affected by many obscure #ifdef and if we have #ifdef then
it's usually to be compatible with some libc, non-linux systems, old
gcc, etc.

Anyway, it seems the conclusion is to continue with vX.Y.Z :-)

Thanks!

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: versioning

[Sami Kerola]

On 17 May 2017 at 22:09, Karel Zak <kzak@redhat.com> wrote:
> On Wed, May 17, 2017 at 09:07:49PM +0200, Ruediger Meier wrote:
>> I'm not talking about making things incompatible just to be incompatible
>> but about ugly, outdated ifdefs which probably nobody needs anymore but
>> also nobody would touch unless we actively review this.
>
> This would be better to discuss per patch. I don't think the current
> code is affected by many obscure #ifdef and if we have #ifdef then
> it's usually to be compatible with some libc, non-linux systems, old
> gcc, etc.
>
> Anyway, it seems the conclusion is to continue with vX.Y.Z :-)

So will we get 3.0.0 next and stick with 3.y.z for couple years until
numbers grow large?  Then v4.y.z and so on.  My initial thinking was really
as simple as 2.30.0 is a bit large number, and the 2 has not changed for 10
years so maybe it's time to update that.

Seeing v31 proposal was interesting, but no.  Two number system could also
work fine, but there does not seem to be apetite to that.  Lets go with
concencus and stick with X.Y.Z format.

Now when we are talking about versioning - do we get much benefit from rcN
series?  As far I can tell the project is good shape to release after every
single commit.  What I don't see is distros using rc series for any users so
currently they primarily tell to contributors 'stop sending intrusive crazy
stuff for couple weeks, a release is about to happen'.  And if that's all
these releases do the same could be achieved by sending a maintainer note to
maillist informing when is the expected day of next release.

In short dropping the -rc's in favour of releasing for real more often is
something I would like to see.

-- 
Sami Kerola
http://www.iki.fi/kerolasa/

Re: versioning

[Karel Zak]

On Thu, May 18, 2017 at 10:29:30AM +0100, Sami Kerola wrote:
> On 17 May 2017 at 22:09, Karel Zak <kzak@redhat.com> wrote:
> > On Wed, May 17, 2017 at 09:07:49PM +0200, Ruediger Meier wrote:
> >> I'm not talking about making things incompatible just to be incompatible
> >> but about ugly, outdated ifdefs which probably nobody needs anymore but
> >> also nobody would touch unless we actively review this.
> >
> > This would be better to discuss per patch. I don't think the current
> > code is affected by many obscure #ifdef and if we have #ifdef then
> > it's usually to be compatible with some libc, non-linux systems, old
> > gcc, etc.
> >
> > Anyway, it seems the conclusion is to continue with vX.Y.Z :-)
> 
> So will we get 3.0.0 next and stick with 3.y.z for couple years until

Seems like misunderstanding, I've thought that the current v2.nn is
good enough and we will continue with it (and maybe one day after some
significant changes we will switch to v3.nn, and so on).

> numbers grow large?  Then v4.y.z and so on.  My initial thinking was really
> as simple as 2.30.0 is a bit large number, and the 2 has not changed for 10
> years so maybe it's time to update that.

...

> Now when we are talking about versioning - do we get much benefit from rcN
> series? 

Well, it would be nice to somehow force people to use -rcN release to
test things :-)

The important thing on rcN is that we have official tarball, so you
can use it independently on git, add to distros etc.

I usually push all rc releases to unstable Fedora, sometimes I get feedback.

-rc1 is also time when I work on reports from coverity and another
static analyzers. So, for me it makes sense, but it's nothing critical.

> As far I can tell the project is good shape to release after every
> single commit.  What I don't see is distros using rc series for any users so
> currently they primarily tell to contributors 'stop sending intrusive crazy
> stuff for couple weeks, a release is about to happen'.  And if that's all
> these releases do the same could be achieved by sending a maintainer note to
> maillist informing when is the expected day of next release.

We need time to freeze the code (at least for one week) for
translators (usually -rc2). This is the minimal requirement.

> In short dropping the -rc's in favour of releasing for real more often is
> something I would like to see.

My wish is to release more often (~4 month), but not sure why it's 
always more months :-))

For v2.30 my schedule is:

   - Thu May 23 -rc2
   - Thu May 30 release

For the next releases it would be probably nice to prepare schedule
for all year and always publish schedule for the next release
immediately after the previous release

   - Sep 16 -- feature freeze, no invasive changes allowed (aka rc1)
   - Sep 19 -- strings freeze, translations (aka rc2)
   - Sep 26 -- v2.31

   - Jan 16 -- feature freeze, no invasive changes allowed (aka rc1)
   - Jan 23 -- strings freeze, translations (aka rc2)
   - Jan 30 -- v2.32

   ... etc.

It means release every 4 month, last Tuesday in the month; one week
between -rcN (so... 14 days freeze every 4 month, IMHO not so bad).

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: versioning

[Ruediger Meier]

On Thursday 18 May 2017, Sami Kerola wrote:
> On 17 May 2017 at 22:09, Karel Zak <kzak@redhat.com> wrote:
> > On Wed, May 17, 2017 at 09:07:49PM +0200, Ruediger Meier wrote:
> >> I'm not talking about making things incompatible just to be
> >> incompatible but about ugly, outdated ifdefs which probably nobody
> >> needs anymore but also nobody would touch unless we actively
> >> review this.
> >
> > This would be better to discuss per patch. I don't think the
> > current code is affected by many obscure #ifdef and if we have
> > #ifdef then it's usually to be compatible with some libc, non-linux
> > systems, old gcc, etc.
> >
> > Anyway, it seems the conclusion is to continue with vX.Y.Z :-)
>
> So will we get 3.0.0 next and stick with 3.y.z for couple years until
> numbers grow large?  Then v4.y.z and so on.  My initial thinking was
> really as simple as 2.30.0 is a bit large number, and the 2 has not
> changed for 10 years so maybe it's time to update that.
>
> Seeing v31 proposal was interesting, but no.  Two number system could
> also work fine, but there does not seem to be apetite to that.  Lets
> go with concencus and stick with X.Y.Z format.
>
> Now when we are talking about versioning - do we get much benefit
> from rcN series?

I think some distro maintainers use and test it to report bugs before 
final release. Maybe even translaters use it.  The benfit for them is 
that they need less dependencies for the build. Also the rcN tag makes 
them able to get informed automatically a few times per year rather 
then continuously following our master branch or mailing list.

Only for cosmetics I would remove the old rcN tarballs from the server. 
Nobody needs them nor should still use them after release.

> As far I can tell the project is good shape to 
> release after every single commit.  What I don't see is distros using
> rc series for any users so currently they primarily tell to
> contributors 'stop sending intrusive crazy stuff for couple weeks, a
> release is about to happen'.  And if that's all these releases do the
> same could be achieved by sending a maintainer note to maillist
> informing when is the expected day of next release.
>
> In short dropping the -rc's in favour of releasing for real more
> often is something I would like to see.

IMO we are releasing often enough. Personally I find the stable bug fix 
releases most interesting. If I want a more recent UL I would build 
from git anyways.

cu,
Rudi

Re: versioning

[J William Piggott]

On 05/18/2017 06:36 AM, Karel Zak wrote:

 8< ---

> 
> The important thing on rcN is that we have official tarball, so you
> can use it independently on git, add to distros etc.

 8< ---

Karel,
I pull from github and haven't seen a new tag since v2.29. Perhaps I
should be pulling from kernel.org, but github should work, no?

Also, it looks like Documentation/source-code-management.txt needs to be
updated. There are no bugfix branches, only tags. Isn't the KNOWN BUGS:
referring to the v2.13.1 branch as a typo, not the tag?

>     Karel
> 

Re: versioning

[Karel Zak]

On Thu, May 18, 2017 at 02:08:49PM -0400, J William Piggott wrote:
> On 05/18/2017 06:36 AM, Karel Zak wrote:
> 
>  8< ---
> 
> > 
> > The important thing on rcN is that we have official tarball, so you
> > can use it independently on git, add to distros etc.
> 
>  8< ---
> 
> Karel,
> I pull from github and haven't seen a new tag since v2.29. Perhaps I
> should be pulling from kernel.org, but github should work, no?

I push to the both repos in the same time

$ git push; git push github master; git push --tags; git push github --tags
Everything up-to-date
Everything up-to-date
Everything up-to-date
Everything up-to-date

And I see the tags at https://github.com/karelzak/util-linux/tags

> Also, it looks like Documentation/source-code-management.txt needs to be
> updated. There are no bugfix branches, only tags.

Good point. Updated.

> Isn't the KNOWN BUGS:
> referring to the v2.13.1 branch as a typo, not the tag?

$ git tag -l | grep v2.13.1
v2.13.1
v2.13.1-REAL
v2.13.1-rc1
v2.13.1-rc2
v2.13.1.1

the first line is unwanted tag... it would be possible to delete it, but I
don't think that remove already published tags is a good idea.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: versioning

[Rüdiger Meier]

On 05/18/2017 09:56 PM, Karel Zak wrote:
> On Thu, May 18, 2017 at 02:08:49PM -0400, J William Piggott wrote:
>> On 05/18/2017 06:36 AM, Karel Zak wrote:
>>
>>   8< ---
>>
>>>
>>> The important thing on rcN is that we have official tarball, so you
>>> can use it independently on git, add to distros etc.
>>
>>   8< ---
>>
>> Karel,
>> I pull from github and haven't seen a new tag since v2.29. Perhaps I
>> should be pulling from kernel.org, but github should work, no?

I think "git pull" does not always give you all the tags. In doubt I do 
explicitly "git fetch --tag remote-name". Maybe "git pull" only pulls 
tags if remote-name == origin, I still don't got the full logic.

> I push to the both repos in the same time
> 
> $ git push; git push github master; git push --tags; git push github --tags
> Everything up-to-date
> Everything up-to-date
> Everything up-to-date
> Everything up-to-date
> 
> And I see the tags at https://github.com/karelzak/util-linux/tags
> 
>> Also, it looks like Documentation/source-code-management.txt needs to be
>> updated. There are no bugfix branches, only tags.
> 
> Good point. Updated.
> 
>> Isn't the KNOWN BUGS:
>> referring to the v2.13.1 branch as a typo, not the tag?
> 
> $ git tag -l | grep v2.13.1
> v2.13.1
> v2.13.1-REAL
> v2.13.1-rc1
> v2.13.1-rc2
> v2.13.1.1
> 
> the first line is unwanted tag... it would be possible to delete it, but I
> don't think that remove already published tags is a good idea.

It should not be a problem to delete tags like it's no problem to delete 
branches. Only rebasing branches or re-creating conflicting tags could 
be annoying or at least confusing.

cu,
Rudi



>      Karel
> 

Re: versioning

[Karel Zak]

On Thu, May 18, 2017 at 10:55:41PM +0200, Rüdiger Meier wrote:
> It should not be a problem to delete tags like it's no problem to delete
> branches. Only rebasing branches or re-creating conflicting tags could be
> annoying or at least confusing.

It should be re-taged rather than deleted and it's the problem. I don't
think it's important after the years.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: versioning

[J William Piggott]

On 05/18/2017 04:55 PM, Rüdiger Meier wrote:
> 
> 
> On 05/18/2017 09:56 PM, Karel Zak wrote:
>> On Thu, May 18, 2017 at 02:08:49PM -0400, J William Piggott wrote:
>>> On 05/18/2017 06:36 AM, Karel Zak wrote:
>>>
>>>   8< ---
>>>
>>>>
>>>> The important thing on rcN is that we have official tarball, so you
>>>>
>>>> can use it independently on git, add to distros etc.
>>>>
>>>
>>>   8< ---
>>>
>>> Karel, I pull from github and haven't seen a new tag since v2.29.
>>> Perhaps I should be pulling from kernel.org, but github should work,
>>> no?
> 
> I think "git pull" does not always give you all the tags. In doubt I
> do explicitly "git fetch --tag remote-name".  Maybe "git pull" only
> pulls tags if remote-name == origin, I still don't got the full logic.

Using 'git pull' against master fetched the tags up through v2.29. Then
it stopped.

git-pull(1): By default, tags that point at objects that are downloaded
from the remote repository are fetched and stored locally.

If a tag is created from the master branch, then (with the default
configuration) pulling the master branch will pull the tag as well.

I think perhaps Karel changed his bugfix release workflow and started
creating them from a working branch. I say that because the
v2.30-ReleaseNotes file never hit my local repo, the master branch,
until May 16th. That is why I submitted my patch for it as a simple diff
instead of a git format-patch.

It seems to me that the working branch should be merged into master
first, and then create the tag, tarball, etc. from master.  That way
pulling master will fetch the release tags. That should be expected
behavior.

IMO, creating releases from an ephemeral branch, or anything other than
master, is asking for headaches.

>> I push to the both repos in the same time
>> $ git push; git push github master; git push --tags; git push github --tags

I think it would be better to:

git push --follow-tags; git push --follow-tags github master

This would be a good crosscheck to know that the release tags were
created against master and not some other branch.

Also, one day you may want to have some private tags and --tags will
push everything.  Whereas, --follow-tags will only push tags associated
with what is being pushed, that is, the master branch.


 8< ---

>>
>>> Isn't the KNOWN BUGS: referring to the v2.13.1 branch as a typo, not
>>> the tag?
>>
>> $ git tag -l | grep v2.13.1 v2.13.1 v2.13.1-REAL
>>
>> v2.13.1-rc1
>>
>> v2.13.1-rc2
>>
>> v2.13.1.1
>>
>> the first line is unwanted tag...  it would be possible to delete it,
>> but I don't think that remove already published tags is a good idea.

I see, but isn't the v2.13.1 branch a 'bug' also, because there are not
any bugfix release branches? Well like you said, it's old and doesn't
matter much now.


> 
> It should not be a problem to delete tags like it's no problem to
> delete branches.  Only rebasing branches or re-creating conflicting
> tags could be annoying or at least confusing.
> 
> 
> cu, Rudi
> 
> 
> 
>>     
>> Karel
>>
> -- To unsubscribe from this list: send the line "unsubscribe
> util-linux" in
> 
> the body of a message to majordomo@vger.kernel.org
> 
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> 
> 

Re: versioning

[Karel Zak]

On Fri, May 19, 2017 at 03:00:14PM -0400, J William Piggott wrote:
> > 
> > I think "git pull" does not always give you all the tags. In doubt I
> > do explicitly "git fetch --tag remote-name".  Maybe "git pull" only
> > pulls tags if remote-name == origin, I still don't got the full logic.
> 
> Using 'git pull' against master fetched the tags up through v2.29. Then
> it stopped.
> 
> git-pull(1): By default, tags that point at objects that are downloaded
> from the remote repository are fetched and stored locally.
> 
> If a tag is created from the master branch, then (with the default
> configuration) pulling the master branch will pull the tag as well.
> 
> I think perhaps Karel changed his bugfix release workflow and started
> creating them from a working branch. 

I always use master branch.

$ git branch --contains  v2.30-rc1
* master

> I say that because the
> v2.30-ReleaseNotes file never hit my local repo, the master branch,
> until May 16th. That is why I submitted my patch for it as a simple diff
> instead of a git format-patch.

https://github.com/karelzak/util-linux/blob/master/Documentation/releases/v2.30-ReleaseNotes
                                            ^^^^^^

as well as on kernel.org:

https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/tag/?h=v2.30-rc1

> It seems to me that the working branch should be merged into master
> first, and then create the tag, tarball, etc. from master.  That way
> pulling master will fetch the release tags. That should be expected
> behavior.
> 
> IMO, creating releases from an ephemeral branch, or anything other than
> master, is asking for headaches.

Maybe you need 'git clean -xdf' before 'git pull' or so.

> >> I push to the both repos in the same time
> >> $ git push; git push github master; git push --tags; git push github --tags
> 
> I think it would be better to:
> 
> git push --follow-tags; git push --follow-tags github master

$ git push --follow-tags; git push --follow-tags github master
Everything up-to-date
Everything up-to-date

> This would be a good crosscheck to know that the release tags were
> created against master and not some other branch.
> 
> Also, one day you may want to have some private tags and --tags will
> push everything.  Whereas, --follow-tags will only push tags associated
> with what is being pushed, that is, the master branch.

OK.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: versioning

[J William Piggott]

On 05/20/2017 03:34 PM, Karel Zak wrote:
> On Fri, May 19, 2017 at 03:00:14PM -0400, J William Piggott wrote:
>> git-pull(1): By default, tags that point at objects that are downloaded
>> from the remote repository are fetched and stored locally.
>>
>> If a tag is created from the master branch, then (with the default
>> configuration) pulling the master branch will pull the tag as well.
>>
>> I think perhaps Karel changed his bugfix release workflow and started
>> creating them from a working branch. 
> 
> I always use master branch.
> 
> $ git branch --contains  v2.30-rc1
> * master
>

So, I muddied the waters by talking about two different topics.
What I really want to discuss are bugfix releases: v2.xx.x.

The following comment should have been a separate topic. I mentioned it
only because the odd behavior that I experienced with the recent rc
release sparked the thought that the bugfix releases are being created
in a working branch and that could explain why 'git pull' is not
fetching their tags.

>> I say that because the
>> v2.30-ReleaseNotes file never hit my local repo, the master branch,
>> until May 16th. That is why I submitted my patch for it as a simple diff
>> instead of a git format-patch.
> 
> https://github.com/karelzak/util-linux/blob/master/Documentation/releases/v2.30-ReleaseNotes
>                                             ^^^^^^
> 
> as well as on kernel.org:
> 
> https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/tag/?h=v2.30-rc1

I wasn't trying to say that this file isn't in 'master', nor that the
stable releases cannot be reached from 'master'; they certainly can be
as they are in the 'master' commit log.

What I was saying is that the release was on May 12. The commit the tag
references hit my repo on May 14, but the v2.30-ReleaseNotes file did
not pull until May 16; May 15 had nothing:

$ find -newermt "-12 day" -printf "%TD %p\n" | sort

 8< ...

05/14/17 ./AUTHORS
05/14/17 ./NEWS
05/14/17 ./aclocal.m4
05/14/17 ./config.h.in
05/14/17 ./configure.ac
05/14/17 ./po/ca.po

 8< ...

05/16/17 ./Documentation/TODO
05/16/17 ./Documentation/releases/v2.30-ReleaseNotes

This seems odd to me, but has all worked out now. The v2.30-rc1 tag
contains the unpatched v2.30-ReleaseNotes without the security warnings,
but I guess that is what v2.30-rc2 is for ;)

Enough of that, the real topic is below.

> 
>> It seems to me that the working branch should be merged into master
>> first, and then create the tag, tarball, etc. from master.  That way
>> pulling master will fetch the release tags. That should be expected
>> behavior.
>>
>> IMO, creating releases from an ephemeral branch, or anything other than
>> master, is asking for headaches.
> 
> Maybe you need 'git clean -xdf' before 'git pull' or so.
>

The bugfix tags 2.xx.x are from another branch and not reachable from
'master', it's not because my local repo is dirty. Here is an example
with a fresh repo:

S git clone https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git
 8< ...
$ cd util-linux
$ git branch --contains v2.29.1  
$ git branch --contains v2.29.2
$ git branch --contains v2.28.1
$ git branch --contains v2.27.1
$ git branch --contains v2.26.1
$ git branch --contains v2.25.1
$ git branch --contains v2.24.1
$ git branch --contains v2.23.1
$ git branch --contains v2.22.1
$ git branch --contains v2.21.1
$ git branch --contains v2.20.1
$ git branch --contains v2.19.1
$ git branch --contains v2.17.1
$ git branch --contains v2.16.1
$ git branch --contains v2.15.1
$ git branch --contains v2.14.1
$ git branch --contains v2.13.1

For example this tag was created from a working branch:

$ git show v2.29.1

 8< ...

commit 9ebc8a7a882ddfd93bc3262514791a0dcaadba09
Author: Karel Zak <kzak@redhat.com>
Date:   Fri Jan 20 14:13:08 2017 +0100

    build-sys: release++ (v2.29.1)
    
    Signed-off-by: Karel Zak <kzak@redhat.com>

 8< ...
 ____________________________________________________

The commit, and therefore the tag, is not in 'master' and is not
reachable from master.

Some issues with this model:

* 'git pull upstream master', etcetera, will not fetch the bugfix
     release tags because they are not reachable from 'master'.
     This could be unexpected behavior for someone new to the project.

* A checked-out bugfix release tag has all of the releases in the NEWS
     file. Whereas, 'master' omits the bugfix releases.

* A checked-out bugfix release tag has all of the v*-ReleaseNotes.
     Whereas, 'master' omits all of the bugfix v2.xx.x-ReleaseNotes.

* The previous two make these orphaned tags more complete then 'master' is.

* I don't know this for a fact, but I suspect that due to the tags not
    being reachable from any branch that they might have to store the
    entire file tree? If yes, it means more bandwidth and storage use.

These aren't issues for me personally, I just thought it was something
the project should consider.

My thoughts are that bugfix releases should be committed to 'master' the
same as the stable/rc releases are. Then the tag created from that commit.


>>>> I push to the both repos in the same time
>>>> $ git push; git push github master; git push --tags; git push github --tags
>>
>> I think it would be better to:
>>
>> git push --follow-tags; git push --follow-tags github master
> 
> $ git push --follow-tags; git push --follow-tags github master
> Everything up-to-date
> Everything up-to-date
>

Well, 'git push --tags' already uploaded all of the tags, so at the moment
using --follow-tags isn't very meaningful. It could be in the future
though. Of course, if the bugfix tags continue to be unreachable from
master, then you will have to go back to using 'git push --tags'.


>> This would be a good crosscheck to know that the release tags were
>> created against master and not some other branch.
>>
>> Also, one day you may want to have some private tags and --tags will
>> push everything.  Whereas, --follow-tags will only push tags associated
>> with what is being pushed, that is, the master branch.
> 
> OK.
> 
>     Karel
> 

Re: versioning

[Karel Zak]

On Mon, May 22, 2017 at 05:37:28PM -0400, J William Piggott wrote:
> My thoughts are that bugfix releases should be committed to 'master' the
> same as the stable/rc releases are. Then the tag created from that commit.

How do you want to commit bugfix release (e.g. v2.29.2) to the
'master' if the master and 'stable/' branches contain a different
code? 

The current workflow:

 1) development (branch: <master>)

 2) master release (tags: v2.29-rc1, v2.29-rc2, v2.29, branch: <master>)

 3) development (work on v2.30, branch: <master>)

 4) fork -- create a new branch <stable/v2.29> based on tag v2.29

     4a) new patches or cherry-pick patches from <master> (branch: <stable/v2.29>)

     4b) stable release (tag: v2.29.1, branch: <stable/v2.29>)

     4c) another patches, another release (tag: v2.29.2, branch: <stable/v2.29>)

 5) master release v2.30 (branch: <master>)
    ...


where 3) and 4) happen in the same time.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: versioning

[Karel Zak]

On Tue, May 23, 2017 at 09:57:33AM +0200, Karel Zak wrote:
> On Mon, May 22, 2017 at 05:37:28PM -0400, J William Piggott wrote:
> > My thoughts are that bugfix releases should be committed to 'master' the
> > same as the stable/rc releases are. Then the tag created from that commit.
> 
> How do you want to commit bugfix release (e.g. v2.29.2) to the
> 'master' if the master and 'stable/' branches contain a different
> code? 
> 
> The current workflow:
> 
>  1) development (branch: <master>)
> 
>  2) master release (tags: v2.29-rc1, v2.29-rc2, v2.29, branch: <master>)
> 
>  3) development (work on v2.30, branch: <master>)
> 
>  4) fork -- create a new branch <stable/v2.29> based on tag v2.29
> 
>      4a) new patches or cherry-pick patches from <master> (branch: <stable/v2.29>)
> 
>      4b) stable release (tag: v2.29.1, branch: <stable/v2.29>)
> 
>      4c) another patches, another release (tag: v2.29.2, branch: <stable/v2.29>)
> 
>  5) master release v2.30 (branch: <master>)
>     ...
> 
> 
> where 3) and 4) happen in the same time.

And yes, NEWS file in the master does not contain info about
maintenance release (e.g. v2.29.1). Maybe it's mistake.

This information is in the ReleaseNotes where are links to the
previous maintenance releases. 

We can add a hint about maintenance releases to the master branch NEWS
file, but stable maintenance tags (v2.29.1) has to be in the stable/
branches. It's released code what has to be tagged and signed.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: versioning

[J William Piggott]

On 05/23/2017 04:05 AM, Karel Zak wrote:
> On Tue, May 23, 2017 at 09:57:33AM +0200, Karel Zak wrote:
>> On Mon, May 22, 2017 at 05:37:28PM -0400, J William Piggott wrote:
>>> My thoughts are that bugfix releases should be committed to 'master' the
>>> same as the stable/rc releases are. Then the tag created from that commit.
>>
>> How do you want to commit bugfix release (e.g. v2.29.2) to the
>> 'master' if the master and 'stable/' branches contain a different
>> code? 
>>
>> The current workflow:
>>
>>  1) development (branch: <master>)
>>
>>  2) master release (tags: v2.29-rc1, v2.29-rc2, v2.29, branch: <master>)
>>
>>  3) development (work on v2.30, branch: <master>)
>>
>>  4) fork -- create a new branch <stable/v2.29> based on tag v2.29
>>
>>      4a) new patches or cherry-pick patches from <master> (branch: <stable/v2.29>)
>>
>>      4b) stable release (tag: v2.29.1, branch: <stable/v2.29>)
>>
>>      4c) another patches, another release (tag: v2.29.2, branch: <stable/v2.29>)
>>
>>  5) master release v2.30 (branch: <master>)
>>     ...
>>
>>
>> where 3) and 4) happen in the same time.

Argh, my brain was broken. I wrongheadedly believed that this project
was using linear development.

> 
> And yes, NEWS file in the master does not contain info about
> maintenance release (e.g. v2.29.1). Maybe it's mistake.

No, I was the mistake ;)

> 
> This information is in the ReleaseNotes where are links to the
> previous maintenance releases. 
> 
> We can add a hint about maintenance releases to the master branch NEWS
> file, but stable maintenance tags (v2.29.1) has to be in the stable/
> branches. It's released code what has to be tagged and signed.

It's all clear now that you've pulled my head out of ... its 'master'
branch walled garden. The stable maintenance tags are not reachable
from, pulled by, or have anything else to do with the 'master' branch.
They belong only to their respective forked stable branches being developed
independently. Hinting about them in master would probably be misleading.

I think I will submit a patch to add something to Documentation about
this so that someone else might not ask the same dumb questions. With
your permission, I might include your well written workflow description.

Sorry for wasting your time Karel (and anyone else reading this). Thank
you for setting me straight.


> 
>     Karel
> 

Re: versioning

[Ruediger Meier]

On Tuesday 23 May 2017, J William Piggott wrote:
> On 05/23/2017 04:05 AM, Karel Zak wrote:
> > On Tue, May 23, 2017 at 09:57:33AM +0200, Karel Zak wrote:
> >> On Mon, May 22, 2017 at 05:37:28PM -0400, J William Piggott wrote:
> >>> My thoughts are that bugfix releases should be committed to
> >>> 'master' the same as the stable/rc releases are. Then the tag
> >>> created from that commit.
> >>
> >> How do you want to commit bugfix release (e.g. v2.29.2) to the
> >> 'master' if the master and 'stable/' branches contain a different
> >> code?
> >>
> >> The current workflow:
> >>
> >>  1) development (branch: <master>)
> >>
> >>  2) master release (tags: v2.29-rc1, v2.29-rc2, v2.29, branch:
> >> <master>)
> >>
> >>  3) development (work on v2.30, branch: <master>)
> >>
> >>  4) fork -- create a new branch <stable/v2.29> based on tag v2.29
> >>
> >>      4a) new patches or cherry-pick patches from <master> (branch:
> >> <stable/v2.29>)
> >>
> >>      4b) stable release (tag: v2.29.1, branch: <stable/v2.29>)
> >>
> >>      4c) another patches, another release (tag: v2.29.2, branch:
> >> <stable/v2.29>)
> >>
> >>  5) master release v2.30 (branch: <master>)
> >>     ...
> >>
> >>
> >> where 3) and 4) happen in the same time.
>
> Argh, my brain was broken. I wrongheadedly believed that this project
> was using linear development.
>
> > And yes, NEWS file in the master does not contain info about
> > maintenance release (e.g. v2.29.1). Maybe it's mistake.
>
> No, I was the mistake ;)
>
> > This information is in the ReleaseNotes where are links to the
> > previous maintenance releases.
> >
> > We can add a hint about maintenance releases to the master branch
> > NEWS file, but stable maintenance tags (v2.29.1) has to be in the
> > stable/ branches. It's released code what has to be tagged and
> > signed.
>
> It's all clear now that you've pulled my head out of ... its 'master'
> branch walled garden. The stable maintenance tags are not reachable
> from, pulled by, or have anything else to do with the 'master'
> branch. They belong only to their respective forked stable branches
> being developed independently. Hinting about them in master would
> probably be misleading.
>
> I think I will submit a patch to add something to Documentation about
> this so that someone else might not ask the same dumb questions. With
> your permission, I might include your well written workflow
> description.

FYI there is also "man 7 gitworkflows", worth to read IMO.

Beside the trivial fact that they use "maint" instead of "stable" they 
always provide one non-versioned "stable" branch which contains *all* 
tags, more easy to be followed by users. To be able to do that they 
*commit* bugfixes only to "stable" and *merge* them into master 
(instead of cherry-picking from master).

cu,
Rudi

> Sorry for wasting your time Karel (and anyone else reading this).
> Thank you for setting me straight.
>
> >     Karel
>
> --
> To unsubscribe from this list: send the line "unsubscribe util-linux"
> in the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: versioning

[J William Piggott]

On 05/23/2017 04:54 PM, J William Piggott wrote:
> 
> I think I will submit a patch to add something to Documentation about
> this so that someone else might not ask the same dumb questions.

I started on this and noticed that the source-code-management.txt and
README files are very similar. README actually has a more complete
version schema breakdown. Is there any reason that they should not be
combined into a single file?

I think maintaining a single file for links, contacts, repo locations,
etc. makes things easier. There are only three files referencing
source-code-management.txt, one of them is README. Seems okay to have
the other two files point at the README file instead?

README includes the mailing list. Is there any reason that the IRC
channel shouldn't be there instead of in howto-contribute.txt?

The howto-contribute.txt file says patches can be sent to the mailing
list or directly to Karel, and points to README for the addresses. Is
there any reason not to have Karel's email contact in the README?


> 
> Sorry for wasting your time Karel (and anyone else reading this). Thank
> you for setting me straight.
> 
> 
>>
>>     Karel
>>
> --
> To unsubscribe from this list: send the line "unsubscribe util-linux" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: versioning

[Karel Zak]

On Sat, May 27, 2017 at 02:55:41PM -0400, J William Piggott wrote:
> 
> 
> On 05/23/2017 04:54 PM, J William Piggott wrote:
> > 
> > I think I will submit a patch to add something to Documentation about
> > this so that someone else might not ask the same dumb questions.
> 
> I started on this and noticed that the source-code-management.txt and
> README files are very similar. README actually has a more complete
> version schema breakdown. Is there any reason that they should not be
> combined into a single file?

No problem, but I'd like to keep all most important information
(=links, addresses, etc.) in the README file.

Send patch :-)

> README includes the mailing list. Is there any reason that the IRC
> channel shouldn't be there instead of in howto-contribute.txt?

Send patch :-)

> The howto-contribute.txt file says patches can be sent to the mailing
> list or directly to Karel, and points to README for the addresses. Is
> there any reason not to have Karel's email contact in the README?

I don't think it's so important, but no problem to change it.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com