Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Nicolas George]

Le quintidi 15 ventôse, an CCXXIV, Timothy Gu a écrit :
> The date is considered to be "good" but perhaps not as necessary.

I think the date should be present too, it is the only information that can
be parsed without any previous knowledge.

> - It should also be gitrevisions(7)-compatible

Extra information can be added in a separate chunk:

version gitrevisions-compatible (extra details)

compn: the date is the date of the latest commit, not the build date. A
three-years-old version will have a three-years-old latest commit.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Hendrik Leppkes]

On Sat, Mar 5, 2016 at 11:26 AM, Carl Eugen Hoyos  wrote:
> Timothy Gu  gmail.com> writes:
>
>> The versioning scheme is supposed to make people's life easier.
>
> The patch would make my life more difficult .
>

If you can't even explain why, then I wouldn't expect many people to listen.
The latest proposal includes the exact same information as before,
plus one more piece of information.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Carl Eugen Hoyos]

Timothy Gu  gmail.com> writes:

> The versioning scheme is supposed to make people's life easier.

The patch would make my life more difficult .

Carl Eugen

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Thilo Borgmann]

Am 04.03.16 um 23:44 schrieb Timothy Gu:
> [...]
> So here I propose the following for the master branch:
> 
> n3.1-dev-N-78911-gf81c81c
>/  |  \  \
>  /|   \\
>   next  distinguish commits since  commit
> release from actual the start ofhash
>   release   time
> 
> For comparison, versions on the release branch are as follows:
> 
> n3.0-4-geb46065
>   /| \
>   /   \  \
> previous commits since  commit
> release  that releasehash
> [...]
> 
>: Current: New
> Master
> Full   : N-78911-gf81c81c   : n3.1-dev-N-78911-gf81c81c
> Shallow clone  : git-2016-03-04-f81c81c : n3.1-dev-gf81c81c
> Gitweb tarball : 3.0.git-f81c81c: n3.1-dev-gf81c81c
> Nothing: 3.0.git: n3.1-dev
> 
> Release branch
> Full   : n3.0-4-geb46065: n3.0.1-dev-4-geb46065
> Shallow clone  : eb46065: n3.0.1-dev-geb56065
> Nothing: 3.0: n3.0.1-dev
> 
> Release
> Full   : n3.0   : n3.0
> Shallow clone  : n3.0   : n3.0
> Nothing: 3.0: n3.0

I had loved to see something like this sooner, thanks!

I think in that form it is in all cases better than it is now.
No more objections from me.

-Thilo

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[compn]

On Fri, 4 Mar 2016 14:44:28 -0800
Timothy Gu  wrote:

> So after all the email exchanges, I think there are certain things
> that our version SHOULD contain:
> 
> - The hash
> - The next release (i.e. n3.1)
> - A way to compare two versions
> 
> The date is considered to be "good" but perhaps not as necessary.

the problem i've seen when helping users when the date is inside the
version string (in mplayer) is that the idiot distros build an old
mplayer 1.1-2016-01-01 right? except mplayer 1.1 was released 3
years ago. in 2013.

they just built a 3 year old tarball two months ago and users install
it like it was new!

which is why ffmpeg and mplayer have the copyright year in the version
string to help. slightly. assuming distros dont mess with it.


> 
> Any objections?
> 

should put it up to a vote what devs and users want to see.

otherwise its just a few vocal devs on the list dictating it for
everyone :P


-compn
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Timothy Gu]

On Fri, Mar 04, 2016 at 08:46:42PM +0100, Reimar Döffinger wrote:
> On 04.03.2016, at 11:24, Nicolas George  wrote:
> 
> > The Git (short) hash carries all the information by itself, so it should be
> > present. But extra, redundant, information can be added for the convenience
> > of users and "supporters".
> > 
> > Basically, the version could be something like
> > "g510046c:N78879-3.0master417-H20160303":
> 
> The formatting is rather ugly but I'd be in favour of something like that.
> An attempt to order the information in increasing detail might be:
> v3.0+417-D20160303-N78879-g510046c
> Note that I'm not convinced the git describe info/branch info/number of
> commits since release is all that useful, but the base release version
> number seems nice to have.

I agree.

> Particularly the branch name can easily be misleading as it can be anyone's
> master, not necessarily the one on ffmpeg.org.

Indeed.

->8--

So after all the email exchanges, I think there are certain things that our
version SHOULD contain:

- The hash
- The next release (i.e. n3.1)
- A way to compare two versions

The date is considered to be "good" but perhaps not as necessary.

So here I propose the following for the master branch:

n3.1-dev-N-78911-gf81c81c
   /  |  \  \
 /|   \\
  next  distinguish commits since  commit
release from actual the start ofhash
  release   time

For comparison, versions on the release branch are as follows:

n3.0-4-geb46065
/| \
  /   \  \
previous commits since  commit
release  that releasehash

A few reasons why I chose this style for master branch rather than some other:

- I want it to bear some resemblance to our original style
   - which also happens to satisfy Carl's perhaps unjustified dependency on it
- I want it to be somewhat consistent with our release branch version
- It should also be gitrevisions(7)-compatible

I would also like to raise an awareness of versioning when full Git metadata
is not available. version.sh tries its best to get information, and usually
ends up with one of the following circumstances. However, the format is wildly
inconsistent, and I want to fix this once and for all.

I can utilize the RELEASE file to provide information on our next release,
even when tags are unavailable.

   : Current: New
Master
Full   : N-78911-gf81c81c   : n3.1-dev-N-78911-gf81c81c
Shallow clone  : git-2016-03-04-f81c81c : n3.1-dev-gf81c81c
Gitweb tarball : 3.0.git-f81c81c: n3.1-dev-gf81c81c
Nothing: 3.0.git: n3.1-dev

Release branch
Full   : n3.0-4-geb46065: n3.0.1-dev-4-geb46065
Shallow clone  : eb46065: n3.0.1-dev-geb56065
Nothing: 3.0: n3.0.1-dev

Release
Full   : n3.0   : n3.0
Shallow clone  : n3.0   : n3.0
Nothing: 3.0: n3.0

Any objections?

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Thilo Borgmann]

Am 04.03.16 um 22:50 schrieb Timothy Gu:
> On Fri, Mar 04, 2016 at 06:48:04PM +0100, Thilo Borgmann wrote:
>> Am 04.03.16 um 17:57 schrieb Timothy Gu:
>>> On Fri, Mar 04, 2016 at 10:55:42AM +0100, Thilo Borgmann wrote:
 Am 04.03.16 um 08:58 schrieb wm4:
>
> Being able to see the, well, version in the version output (instead of
> random numbers) sounds like a pretty convincing argument.

 Neither a good play on words nor elaborative; not even helpful.

 You say they are random numbers, CE says it is continuous. What is correct?
>>>
>>> It is continuous. But to the user's eye, N-71234 is no different from 
>>> N-41234,
>>> and hence "random."
>>
>> I assume that if there is no difference in the user's eye between
>> N-71234 and N-41234 then there is also no difference for that user
>> between dev-123 and dev-346.
> 
> That's not the point. ...

From here I really can't follow you...

> The point is that there is something before the dev
> part, and that's what makes the difference.

Do you mean the absolute anchor point for dev-123 (completely:
v3.0-dev123) which leads to "from release 3.0 go 123 steps further"?
If so, yes, it is different to N-12345 which leads to "go 12345 steps".
In that case, I would still prefer "absolute position" above "anchor +
relative position".


> When I said "no different," I meant except the fact that N-71234 is obviously
> newer. The fact that it fails to convey any additional information is the
> issue we are trying to attack.

With what I'm absolutely fine - I would like to see the release tag in
front. To determine how far away the build is from that release, I would
still prefer the absolute number (like said above).
Why? If I understand this correctly, the dev-123 tag version has a
certain disadvantage against N-tags.
Let's say there is v3.0-dev123.
Let's say there is v3.5-dev3.
Let's assume v3.5 was released right after 3.0 (3.1, 3.2, etc are not
existing)
Now, the question of interest is, how big is the difference between
v3.0-dev123 and v3.5-dev3?
This is the question this is all about, isn't it?
Since I do not know, how many commits there were at all for version 3.0,
I cannot answer the question. Maybe v3.0-dev142 was the last? Maybe
v3.0-dev897?
Let's assume there is v3.0-N-12345 and v3.5-N-12389... I can tell you
and estimate whatever 44 commits are worth estimating, no matter which
commit exactly raised version minor from 0 to 5.

But maybe I'm totally off-minded here.


 So what about the release tag? Well it is a quite useful extension because 
 of
 the already mentioned possibility of determining the existing features at 
 once.
 I'm pro adding it to the version string.

 The tag-tag? (devxy) I don't see it anywhere except in git and therefore 
 it is
 uselessly redundant to the existing hash tag in my eyes. Why add another 
 more
 roughly estimation of the users repo-state? I don't think this should be 
 added
 to the version string.
>>>
>>> Can you elaborate on this? I am not sure I understand everything you are
>>> saying. Specfically, what is "devxy"?
>>
>> The core concern about it is that is just redundant. I assume Timo to be
>> correct about:
>>
>> "A new dev tag is made every time a release is branched off, to indicate
>> development of the next ffmpeg version started there, ..."
>>
>> Then there is no gain of information in the dev-123 tag if there is
>> already the release number given. In that case "v4.5-gdeabdef" tells me
>> the very same as "v4.5-dev-123-gdeabdef" does. If Timo is correct, the
>> can never be a "4.5-dev-789-abcdefg" tag. v4.5 is just enough.
>>
>> Summing it all up for me, I think a release prefix would make perfect
>> sense. Thus, switching from
>>
>> N-12345-abcdefg
>>
>> to
>>
>> v4.5-N-12345-abcdefg
>>
>> should be done for the sake of the users. There is at least CE wanting
>> to stick with N-tags so why not? The only reason I can imagine for
>> getting rid of N-tags and/or including dev-123 tags would be that a
>> native git show command needs it to work properly as well as giving
>> better human readable information.
> 
> I see where you are coming from. I will address this issue in my reply to
> Reimar.

Eh... No - I don't understand. Maybe your reply to Raimar will explain...

-Thilo

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Timothy Gu]

On Fri, Mar 04, 2016 at 06:48:04PM +0100, Thilo Borgmann wrote:
> Am 04.03.16 um 17:57 schrieb Timothy Gu:
> > On Fri, Mar 04, 2016 at 10:55:42AM +0100, Thilo Borgmann wrote:
> >> Am 04.03.16 um 08:58 schrieb wm4:
> >>>
> >>> Being able to see the, well, version in the version output (instead of
> >>> random numbers) sounds like a pretty convincing argument.
> >>
> >> Neither a good play on words nor elaborative; not even helpful.
> >>
> >> You say they are random numbers, CE says it is continuous. What is correct?
> > 
> > It is continuous. But to the user's eye, N-71234 is no different from 
> > N-41234,
> > and hence "random."
> 
> I assume that if there is no difference in the user's eye between
> N-71234 and N-41234 then there is also no difference for that user
> between dev-123 and dev-346.

That's not the point. The point is that there is something before the dev
part, and that's what makes the difference.

When I said "no different," I meant except the fact that N-71234 is obviously
newer. The fact that it fails to convey any additional information is the
issue we are trying to attack.

> 
> 
> >> So what about the release tag? Well it is a quite useful extension because 
> >> of
> >> the already mentioned possibility of determining the existing features at 
> >> once.
> >> I'm pro adding it to the version string.
> >>
> >> The tag-tag? (devxy) I don't see it anywhere except in git and therefore 
> >> it is
> >> uselessly redundant to the existing hash tag in my eyes. Why add another 
> >> more
> >> roughly estimation of the users repo-state? I don't think this should be 
> >> added
> >> to the version string.
> > 
> > Can you elaborate on this? I am not sure I understand everything you are
> > saying. Specfically, what is "devxy"?
> 
> The core concern about it is that is just redundant. I assume Timo to be
> correct about:
> 
> "A new dev tag is made every time a release is branched off, to indicate
> development of the next ffmpeg version started there, ..."
> 
> Then there is no gain of information in the dev-123 tag if there is
> already the release number given. In that case "v4.5-gdeabdef" tells me
> the very same as "v4.5-dev-123-gdeabdef" does. If Timo is correct, the
> can never be a "4.5-dev-789-abcdefg" tag. v4.5 is just enough.
> 
> Summing it all up for me, I think a release prefix would make perfect
> sense. Thus, switching from
> 
> N-12345-abcdefg
> 
> to
> 
> v4.5-N-12345-abcdefg
> 
> should be done for the sake of the users. There is at least CE wanting
> to stick with N-tags so why not? The only reason I can imagine for
> getting rid of N-tags and/or including dev-123 tags would be that a
> native git show command needs it to work properly as well as giving
> better human readable information.

I see where you are coming from. I will address this issue in my reply to
Reimar.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Reimar Döffinger]

On 04.03.2016, at 11:24, Nicolas George  wrote:

> Le quintidi 15 ventôse, an CCXXIV, Thilo Borgmann a écrit :
>> Neither a good play on words nor elaborative; not even helpful.
>> 
>> You say they are random numbers, CE says it is continuous. What is correct?
>> 
>> Let's assume the N-tag is not random, then it is a useful extension of the
>> pinpointing short hash, since the hashes are not relative to each other (so 
>> to
>> speak random for the human eye) and therefore the N-tags are useful for
>> determining if the user is ahead or behind a certain commit. According to 
>> what
>> CE says, this helps for user support, Not? And if not, why would someone
>> spending most of the time helping users think otherwise?
>> Assuming my thoughts are not based on void assumptions, I'm against removing 
>> the
>> N-tag from the version string.
>> 
>> So what about the release tag? Well it is a quite useful extension because of
>> the already mentioned possibility of determining the existing features at 
>> once.
>> I'm pro adding it to the version string.
>> 
>> The tag-tag? (devxy) I don't see it anywhere except in git and therefore it 
>> is
>> uselessly redundant to the existing hash tag in my eyes. Why add another more
>> roughly estimation of the users repo-state? I don't think this should be 
>> added
>> to the version string.
> 
> Replying here but not specifically to this mail.
> 
> We do not have to choose: there is no hard limit to the amount of
> information that can be encoded in the version, the version string can be
> arbitrarily long, as long as it is convenient.
> 
> The Git (short) hash carries all the information by itself, so it should be
> present. But extra, redundant, information can be added for the convenience
> of users and "supporters".
> 
> Basically, the version could be something like
> "g510046c:N78879-3.0master417-H20160303":

The formatting is rather ugly but I'd be in favour of something like that.
An attempt to order the information in increasing detail might be:
v3.0+417-D20160303-N78879-g510046c
Note that I'm not convinced the git describe info/branch info/number of commits 
since release is all that useful, but the base release version number seems 
nice to have.
Particularly the branch name can easily be misleading as it can be anyone's 
master, not necessarily the one on ffmpeg.org.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Nicolas George]

Le quintidi 15 ventôse, an CCXXIV, Timothy Gu a écrit :
> One object that can be raised against this is that the current versioning and
> the new versioning are both compatible with Git. Try
> 
> git show n3.1-dev-400-g3af71ac
> git show N-78863-g3af71ac

"git show 3af71ac" is enough. With my proposal, depending on the terminal
configuration, double-clicking on the hash would select it alone. Not having
the hash is of course not an option, I am sure we all agree on this point.

> But since the Git hash is already appended I don't see too much problem with
> that.

The thing is you have to think of convenience for everybody.

Think of users who do barely know what a command line is, let alone what Git
is: someone tells them to get a newer version of ffmpeg, they download it
from somewhere, they need to be able to know which one is more recent, and
by how much because upgrading from a three years old version to a two years
and a half one is a bit useless.

Think of advanced users replying on the mailing-lists, they have a Git tree
near at hand at home, but they want to trim their mail in the subway on
their phones.

Having as much information as possible directly at a glance is a benefit
(until it becomes too much information).

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Thilo Borgmann]

Am 04.03.16 um 17:57 schrieb Timothy Gu:
> On Fri, Mar 04, 2016 at 10:55:42AM +0100, Thilo Borgmann wrote:
>> Am 04.03.16 um 08:58 schrieb wm4:
>>>
>>> Being able to see the, well, version in the version output (instead of
>>> random numbers) sounds like a pretty convincing argument.
>>
>> Neither a good play on words nor elaborative; not even helpful.
>>
>> You say they are random numbers, CE says it is continuous. What is correct?
> 
> It is continuous. But to the user's eye, N-71234 is no different from N-41234,
> and hence "random."

I assume that if there is no difference in the user's eye between
N-71234 and N-41234 then there is also no difference for that user
between dev-123 and dev-346.


>> Let's assume the N-tag is not random, then it is a useful extension of the
>> pinpointing short hash, since the hashes are not relative to each other (so 
>> to
>> speak random for the human eye) and therefore the N-tags are useful for
>> determining if the user is ahead or behind a certain commit. According to 
>> what
>> CE says, this helps for user support, Not? And if not, why would someone
>> spending most of the time helping users think otherwise?
> 
> However, you miss the point that the new system allows one to do the same.
> 
> In the old system:
> 
> N-90001-gdeadbef
> N-9-gdeadbee
> N-8-gdeadbed
> 
> In the new system:
> 
> v4.5-dev-123-gdeadbef
> v4.5-dev-122-gdeadbee
> v4.0-dev-45-gdeadbed
> 
> As you can see, they are functionally equivalent: you can immediately tell
> that they are in descending order with both systems.
> 
>> Assuming my thoughts are not based on void assumptions, I'm against removing 
>> the
>> N-tag from the version string.
> 
> I hope I have demonstrated that your concern is mistaken.

Except for the benefit of dev-123 tags you have. Thank you!


>> So what about the release tag? Well it is a quite useful extension because of
>> the already mentioned possibility of determining the existing features at 
>> once.
>> I'm pro adding it to the version string.
>>
>> The tag-tag? (devxy) I don't see it anywhere except in git and therefore it 
>> is
>> uselessly redundant to the existing hash tag in my eyes. Why add another more
>> roughly estimation of the users repo-state? I don't think this should be 
>> added
>> to the version string.
> 
> Can you elaborate on this? I am not sure I understand everything you are
> saying. Specfically, what is "devxy"?

The core concern about it is that is just redundant. I assume Timo to be
correct about:

"A new dev tag is made every time a release is branched off, to indicate
development of the next ffmpeg version started there, ..."

Then there is no gain of information in the dev-123 tag if there is
already the release number given. In that case "v4.5-gdeabdef" tells me
the very same as "v4.5-dev-123-gdeabdef" does. If Timo is correct, the
can never be a "4.5-dev-789-abcdefg" tag. v4.5 is just enough.

Summing it all up for me, I think a release prefix would make perfect
sense. Thus, switching from

N-12345-abcdefg

to

v4.5-N-12345-abcdefg

should be done for the sake of the users. There is at least CE wanting
to stick with N-tags so why not? The only reason I can imagine for
getting rid of N-tags and/or including dev-123 tags would be that a
native git show command needs it to work properly as well as giving
better human readable information.

-Thilo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Timothy Gu]

On Fri, Mar 04, 2016 at 10:20:09AM +, Carl Eugen Hoyos wrote:
> Timo Rothenpieler  rothenpieler.org> writes:
> 
> > The current versioning scheme is indeed simple, but 
> > useless in almost all other aspects.
> 
> FFmpeg has a linear development scheme, how can you call 
> a continuous versioning scheme useless? It reflects 1:1 
> on how FFmpeg is developed.

1. FFmpeg does NOT have a linear development scheme. See `git log --merges`.
2. FFmpeg uses Git, which is inherently distributed and nonlinear.

Therefore your argument again is flawed.

> 
> > It gives no indication about what release it is close to
> 
> But the development here is not release-driven (note that 
> I am not saying it should or shouldn't be, I am just 
> describing how it does work for more than a decade), 
> just look at how the latest release was made: A random 
> snapshot was chosen, not even current known possible 
> security issues or regressions were relevant.

As I have said in my reply to your last mail, and as I will do so again,
whether or not release-driven FFmpeg is irrelevant to this conversation. The
versioning scheme is supposed to make people's life easier. It is NOT designed
to be the epitome of FFmpeg development policies.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Timothy Gu]

On Fri, Mar 04, 2016 at 11:24:31AM +0100, Nicolas George wrote:
> Basically, the version could be something like
> "g510046c:N78879-3.0master417-H20160303":

One object that can be raised against this is that the current versioning and
the new versioning are both compatible with Git. Try

git show n3.1-dev-400-g3af71ac
git show N-78863-g3af71ac

But since the Git hash is already appended I don't see too much problem with
that.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Timothy Gu]

On Fri, Mar 04, 2016 at 10:55:42AM +0100, Thilo Borgmann wrote:
> Am 04.03.16 um 08:58 schrieb wm4:
> > 
> > Being able to see the, well, version in the version output (instead of
> > random numbers) sounds like a pretty convincing argument.
> 
> Neither a good play on words nor elaborative; not even helpful.
> 
> You say they are random numbers, CE says it is continuous. What is correct?

It is continuous. But to the user's eye, N-71234 is no different from N-41234,
and hence "random."

> 
> Let's assume the N-tag is not random, then it is a useful extension of the
> pinpointing short hash, since the hashes are not relative to each other (so to
> speak random for the human eye) and therefore the N-tags are useful for
> determining if the user is ahead or behind a certain commit. According to what
> CE says, this helps for user support, Not? And if not, why would someone
> spending most of the time helping users think otherwise?

However, you miss the point that the new system allows one to do the same.

In the old system:

N-90001-gdeadbef
N-9-gdeadbee
N-8-gdeadbed

In the new system:

v4.5-dev-123-gdeadbef
v4.5-dev-122-gdeadbee
v4.0-dev-45-gdeadbed

As you can see, they are functionally equivalent: you can immediately tell
that they are in descending order with both systems.

> Assuming my thoughts are not based on void assumptions, I'm against removing 
> the
> N-tag from the version string.

I hope I have demonstrated that your concern is mistaken.

> So what about the release tag? Well it is a quite useful extension because of
> the already mentioned possibility of determining the existing features at 
> once.
> I'm pro adding it to the version string.
> 
> The tag-tag? (devxy) I don't see it anywhere except in git and therefore it is
> uselessly redundant to the existing hash tag in my eyes. Why add another more
> roughly estimation of the users repo-state? I don't think this should be added
> to the version string.

Can you elaborate on this? I am not sure I understand everything you are
saying. Specfically, what is "devxy"?

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Nicolas George]

Le quintidi 15 ventôse, an CCXXIV, Thilo Borgmann a écrit :
> Neither a good play on words nor elaborative; not even helpful.
> 
> You say they are random numbers, CE says it is continuous. What is correct?
> 
> Let's assume the N-tag is not random, then it is a useful extension of the
> pinpointing short hash, since the hashes are not relative to each other (so to
> speak random for the human eye) and therefore the N-tags are useful for
> determining if the user is ahead or behind a certain commit. According to what
> CE says, this helps for user support, Not? And if not, why would someone
> spending most of the time helping users think otherwise?
> Assuming my thoughts are not based on void assumptions, I'm against removing 
> the
> N-tag from the version string.
> 
> So what about the release tag? Well it is a quite useful extension because of
> the already mentioned possibility of determining the existing features at 
> once.
> I'm pro adding it to the version string.
> 
> The tag-tag? (devxy) I don't see it anywhere except in git and therefore it is
> uselessly redundant to the existing hash tag in my eyes. Why add another more
> roughly estimation of the users repo-state? I don't think this should be added
> to the version string.

Replying here but not specifically to this mail.

We do not have to choose: there is no hard limit to the amount of
information that can be encoded in the version, the version string can be
arbitrarily long, as long as it is convenient.

The Git (short) hash carries all the information by itself, so it should be
present. But extra, redundant, information can be added for the convenience
of users and "supporters".

Basically, the version could be something like
"g510046c:N78879-3.0master417-H20160303":

- the Git hash is there;

- the strictly increasing count from the N tag is there, Carl Eugen is
  happy;

- 3.0dev417 means "on branch master, 417 commits since branch 3.0 was
  forked" (maybe a better syntax can be found), users who want an estimate
  of the relation between releases and Git snapshots are happy;

- H20160303 is the approximate timestamp of the head commit (preferably the
  CommitDate rather than the AuthorDate), users who want to know how old is
  their version are happy.

Also, we could have a parsing script in tools to translate that into
human-readable information, and possibly fill in the blanks if it has access
to a Git repository. Bonus point if a version of this script is available
online as a CGI.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Carl Eugen Hoyos]

Timo Rothenpieler  rothenpieler.org> writes:

> The current versioning scheme is indeed simple, but 
> useless in almost all other aspects.

FFmpeg has a linear development scheme, how can you call 
a continuous versioning scheme useless? It reflects 1:1 
on how FFmpeg is developed.

> It gives no indication about what release it is close to

But the development here is not release-driven (note that 
I am not saying it should or shouldn't be, I am just 
describing how it does work for more than a decade), 
just look at how the latest release was made: A random 
snapshot was chosen, not even current known possible 
security issues or regressions were relevant.

Carl Eugen

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Thilo Borgmann]

You are skipping everything I think about N-tags you want to patch away... why?

Am 04.03.16 um 11:07 schrieb Timo Rothenpieler:
>> So what about the release tag? Well it is a quite useful extension because of
>> the already mentioned possibility of determining the existing features at 
>> once.
>> I'm pro adding it to the version string.
> 
> The release tags are not made in the master branch, so git describe
> won't pick them up.
> They also don't have a meaning for master, as there are distinct commits
> between the two.

The reason for the version tag is the user, not? The user does not care about
git describe, teh user wants teh release number in his version string.
If I read you correctly you are arguing in some way against your own change?
(not haveing the release tag?)


>> The tag-tag? (devxy) I don't see it anywhere except in git and therefore it 
>> is
>> uselessly redundant to the existing hash tag in my eyes. Why add another more
>> roughly estimation of the users repo-state? I don't think this should be 
>> added
>> to the version string.
> 
> A new dev tag is made every time a release is branched off, to indicate
> development of the next ffmpeg version started there, so using it for
> the version number seems natural to me.

I still see no benefit in adding it. If there is the release tag, I don't need
this because they are redundant. If there is no release tag, the user would
manually find the release number for this tag, not?

-Thilo

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Carl Eugen Hoyos]

wm4  googlemail.com> writes:

> Being able to see the, well, version in the version output 
> (instead of random numbers)

What is random about the version number using current FFmpeg?

Carl Eugen

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Timo Rothenpieler]

> So what about the release tag? Well it is a quite useful extension because of
> the already mentioned possibility of determining the existing features at 
> once.
> I'm pro adding it to the version string.

The release tags are not made in the master branch, so git describe
won't pick them up.
They also don't have a meaning for master, as there are distinct commits
between the two.

> The tag-tag? (devxy) I don't see it anywhere except in git and therefore it is
> uselessly redundant to the existing hash tag in my eyes. Why add another more
> roughly estimation of the users repo-state? I don't think this should be added
> to the version string.

A new dev tag is made every time a release is branched off, to indicate
development of the next ffmpeg version started there, so using it for
the version number seems natural to me.



signature.asc
Description: OpenPGP digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Timo Rothenpieler]

>> Of course, this argument operates on the premise that 
>> making things easier for users is of utmost concern 
>> for us. Please inspire me if this is not the case.
> 
> On the contrary, I believe while the current versioing 
> scheme is simple and understandable, the suggested one 
> is misleading, both for users and when reading user 
> questions.

The current versioning scheme is indeed simple, but useless in almost
all other aspects.
It gives no indication about what release it is close to, so the
ChangeLog becomes useless without digging through the git log first.
It's also counter-intuitive, as people are used to regular version numbers.

Also, releases are also continuously numbered, so I don't see what's
better about the always increasing number based on some old tag.


Will resend the patch without the fetch part, but still, on all of my 3
dev machines i had to manually issue a fetch for the latest tags to show up.



signature.asc
Description: OpenPGP digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Thilo Borgmann]

Am 04.03.16 um 08:58 schrieb wm4:
> On Fri, 4 Mar 2016 08:47:14 +0100
> Thilo Borgmann  wrote:
> 
>> Am 04.03.16 um 08:23 schrieb wm4:
>>> On Fri, 4 Mar 2016 00:55:35 + (UTC)
>>> Carl Eugen Hoyos  wrote:
>>>   
 Timothy Gu  gmail.com> writes:
  
> Of course, this argument operates on the premise that 
> making things easier for users is of utmost concern 
> for us. Please inspire me if this is not the case.

 On the contrary, I believe while the current versioing 
 scheme is simple and understandable, the suggested one 
 is misleading, both for users and when reading user 
 questions.  
>>>
>>> Well, duh, everyone disagrees with you.  
>>
>> Not true. For what I've read, I can't see the benefit of the change.
>> However, changing it should require a real reason and I don't see it.
>>
>> So, what exactly is the benefit of the proposed versioning? Can anyone
>> please elaborate what the current state is and what exactly would make
>> the user's life happier with the new one?
> 
> Being able to see the, well, version in the version output (instead of
> random numbers) sounds like a pretty convincing argument.

Neither a good play on words nor elaborative; not even helpful.

You say they are random numbers, CE says it is continuous. What is correct?

Let's assume the N-tag is not random, then it is a useful extension of the
pinpointing short hash, since the hashes are not relative to each other (so to
speak random for the human eye) and therefore the N-tags are useful for
determining if the user is ahead or behind a certain commit. According to what
CE says, this helps for user support, Not? And if not, why would someone
spending most of the time helping users think otherwise?
Assuming my thoughts are not based on void assumptions, I'm against removing the
N-tag from the version string.

So what about the release tag? Well it is a quite useful extension because of
the already mentioned possibility of determining the existing features at once.
I'm pro adding it to the version string.

The tag-tag? (devxy) I don't see it anywhere except in git and therefore it is
uselessly redundant to the existing hash tag in my eyes. Why add another more
roughly estimation of the users repo-state? I don't think this should be added
to the version string.

-Thilo




___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[wm4]

On Fri, 4 Mar 2016 08:47:14 +0100
Thilo Borgmann  wrote:

> Am 04.03.16 um 08:23 schrieb wm4:
> > On Fri, 4 Mar 2016 00:55:35 + (UTC)
> > Carl Eugen Hoyos  wrote:
> >   
> >> Timothy Gu  gmail.com> writes:
> >>  
> >>> Of course, this argument operates on the premise that 
> >>> making things easier for users is of utmost concern 
> >>> for us. Please inspire me if this is not the case.
> >>
> >> On the contrary, I believe while the current versioing 
> >> scheme is simple and understandable, the suggested one 
> >> is misleading, both for users and when reading user 
> >> questions.  
> > 
> > Well, duh, everyone disagrees with you.  
> 
> Not true. For what I've read, I can't see the benefit of the change.
> However, changing it should require a real reason and I don't see it.
> 
> So, what exactly is the benefit of the proposed versioning? Can anyone
> please elaborate what the current state is and what exactly would make
> the user's life happier with the new one?

Being able to see the, well, version in the version output (instead of
random numbers) sounds like a pretty convincing argument.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Thilo Borgmann]

Am 04.03.16 um 08:23 schrieb wm4:
> On Fri, 4 Mar 2016 00:55:35 + (UTC)
> Carl Eugen Hoyos  wrote:
> 
>> Timothy Gu  gmail.com> writes:
>>
>>> Of course, this argument operates on the premise that 
>>> making things easier for users is of utmost concern 
>>> for us. Please inspire me if this is not the case.  
>>
>> On the contrary, I believe while the current versioing 
>> scheme is simple and understandable, the suggested one 
>> is misleading, both for users and when reading user 
>> questions.
> 
> Well, duh, everyone disagrees with you.

Not true. For what I've read, I can't see the benefit of the change.
However, changing it should require a real reason and I don't see it.

So, what exactly is the benefit of the proposed versioning? Can anyone
please elaborate what the current state is and what exactly would make
the user's life happier with the new one?

-Thilo


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[wm4]

On Fri, 4 Mar 2016 00:55:35 + (UTC)
Carl Eugen Hoyos  wrote:

> Timothy Gu  gmail.com> writes:
> 
> > Of course, this argument operates on the premise that 
> > making things easier for users is of utmost concern 
> > for us. Please inspire me if this is not the case.  
> 
> On the contrary, I believe while the current versioing 
> scheme is simple and understandable, the suggested one 
> is misleading, both for users and when reading user 
> questions.

Well, duh, everyone disagrees with you.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Timothy Gu]

On Fri, Mar 04, 2016 at 12:55:35AM +, Carl Eugen Hoyos wrote:
> Timothy Gu  gmail.com> writes:
> 
> > Of course, this argument operates on the premise that 
> > making things easier for users is of utmost concern 
> > for us. Please inspire me if this is not the case.
> 
> On the contrary, I believe while the current versioing 
> scheme is simple and understandable, the suggested one 
> is misleading, both for users and when reading user 
> questions.

English is not my first language, so I might well have misunderstood. But by
using the phrase "on the contrary" are you claiming that we should not regard
users' opinions as our most important concern?

You have not provided any solid proof of your belief, which itself direct
contradicts the opinion of at least three people, one of which is ironically a
non-FFmpeg developer "user" who you claim to represent and whose opinion you
claim to value.

Therefore, without further elaboration, I propose to regard your argument as
null and void for the purpose of this discussion.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Carl Eugen Hoyos]

Timothy Gu  gmail.com> writes:

> Of course, this argument operates on the premise that 
> making things easier for users is of utmost concern 
> for us. Please inspire me if this is not the case.

On the contrary, I believe while the current versioing 
scheme is simple and understandable, the suggested one 
is misleading, both for users and when reading user 
questions.

Carl Eugen

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Timothy Gu]

On Thu, Mar 03, 2016 at 11:04:09PM +, Carl Eugen Hoyos wrote:
> Timo Rothenpieler  rothenpieler.org> writes:
> 
> > So instead of
> > 
> > N-78885-g966eade
> 
> The continuous numbering scheme is very convenient when 
> answering user questions and it reflects very well the 
> (past and current) development model of FFmpeg that is 
> not release-driven ...

Do I understand correctly that FFmpeg in the future will not version releases
backwards? If that is the case, then the "continuous" bit is a nonissue.

The argument on development model is unrelated to discussion.

> 
> > 
> > One now gets
> > 
> > n3.1-dev-422-g966eade
> 
> ... while I personally find this slightly ugly.

Users seem to disagree. One example of such a complaint is
http://willus.com/author/ffmpegbmark.shtml:

**I continue to be frustrated** with the nightly-build ffmpeg version
numbering. . . . It would be nice if the nightly builds gave some
indication of what major and minor version release they are related to,
even if it's a snapshot build. A version number like N-46936-g8b6aeb1 is
**meaningless to me (and to most other users, I imagine)**. Why is this so
hard? This is where avconv.exe does much better, giving a more
intelligible version number like v9_beta2-255-gb9629ac.

(some emphasis is mine)

Using the version also comes with other advantages. It is now a lot easier to
check if a certain feature is available in a build by looking at the Changelog
(which records release versions, not N-based revision numbers).

Of course, this argument operates on the premise that making things easier for
users is of utmost concern for us. Please inspire me if this is not the case.

Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Hendrik Leppkes]

On Thu, Mar 3, 2016 at 11:20 PM, Timo Rothenpieler
 wrote:
>> Accessing a remote URL in the version script seems like a bad idea to me.
>
> I aggree, but I'm unsure how to propperly address the issue.
> The problem is that a plain "git pull" does not update tags,
> so if you have an older clone you allways updated via git pull, you end
> up with a version number based on an older tag.
>

I don't know what your Git is doing, but fetch and pull automatically
grab the appropriate tags for me.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Carl Eugen Hoyos]

Timo Rothenpieler  rothenpieler.org> writes:

> So instead of
> 
> N-78885-g966eade

The continuous numbering scheme is very convenient when 
answering user questions and it reflects very well the 
(past and current) development model of FFmpeg that is 
not release-driven ...

> 
> One now gets
> 
> n3.1-dev-422-g966eade

... while I personally find this slightly ugly.

Please don't change the versioning system, Carl Eugen

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Timo Rothenpieler]

> Accessing a remote URL in the version script seems like a bad idea to me.

I aggree, but I'm unsure how to propperly address the issue.
The problem is that a plain "git pull" does not update tags,
so if you have an older clone you allways updated via git pull, you end
up with a version number based on an older tag.

The idea behind that fetch command is to fail silently after taking a
maximum of 10 seconds to download the latest tags.

libav (and a lot of other project aswell) just ignores that issue and
uses a plain git describe --tags --always.

> - Hendrik
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 



signature.asc
Description: OpenPGP digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Hendrik Leppkes]

Am 03.03.2016 22:46 schrieb "Timo Rothenpieler" :
>
> The version numbers based on the 15 years old N tag are confusing and
> don't offer a lot of information about what release the version is close
> to.
>
> This patch stops using the N tag and always bases it on the most recent
> dev tag instead. So instead of
>
> N-78885-g966eade
>
> One now gets
>
> n3.1-dev-422-g966eade
>
> Which offers a lot more informational value to users and developers.
> ---
>  version.sh | 9 -
>  1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/version.sh b/version.sh
> index a9d7e39..1c3faf1 100755
> --- a/version.sh
> +++ b/version.sh
> @@ -4,11 +4,10 @@
>
>  # check for git short hash
>  if ! test "$revision"; then
> -if (cd "$1" && grep git RELEASE 2> /dev/null >/dev/null) ; then
> -revision=$(cd "$1" && git describe --tags --match N 2> /dev/null)
> -else
> -revision=$(cd "$1" && git describe --tags --always 2> /dev/null)
> -fi
> +# Optional fetch to make sure latest tags are present
> +(cd "$1" && timeout 10 git fetch --quiet "
https://git.videolan.org/git/ffmpeg.git; "refs/tags/*:refs/tags/*" >
/dev/null 2>&1)
> +
> +revision=$(cd "$1" && git describe --tags --always 2> /dev/null)
>  fi
>
>  # Shallow Git clones (--depth) do not have the N tag:
> --

Accessing a remote URL in the version script seems like a bad idea to me.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Timo Rothenpieler]

The version numbers based on the 15 years old N tag are confusing and
don't offer a lot of information about what release the version is close
to.

This patch stops using the N tag and always bases it on the most recent
dev tag instead. So instead of

N-78885-g966eade

One now gets

n3.1-dev-422-g966eade

Which offers a lot more informational value to users and developers.
---
 version.sh | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/version.sh b/version.sh
index a9d7e39..1c3faf1 100755
--- a/version.sh
+++ b/version.sh
@@ -4,11 +4,10 @@
 
 # check for git short hash
 if ! test "$revision"; then
-if (cd "$1" && grep git RELEASE 2> /dev/null >/dev/null) ; then
-revision=$(cd "$1" && git describe --tags --match N 2> /dev/null)
-else
-revision=$(cd "$1" && git describe --tags --always 2> /dev/null)
-fi
+# Optional fetch to make sure latest tags are present
+(cd "$1" && timeout 10 git fetch --quiet 
"https://git.videolan.org/git/ffmpeg.git; "refs/tags/*:refs/tags/*" > /dev/null 
2>&1)
+
+revision=$(cd "$1" && git describe --tags --always 2> /dev/null)
 fi
 
 # Shallow Git clones (--depth) do not have the N tag:
-- 
2.7.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel