Big Bump in Version needed

[Si]

As an innocent bystander, it looks to me as if the current development releases could do with being labelled 2.6 alphas and not 2.5x variations as I think people (and plugin developers ) are getting a bit confused and not fully apreciating the major improvements and changes going on behind the scenes.

If the version number is bumped and releases labelled as alpha's then even us simple folk would probably realise what's going on.

I'd actually suggest moving to 2.7 as that would my my personal estimate of the jump happening but that could confuse people simpler than me who'd wonder where 2.6 was )


regards

Simon

[Wilbert]

(...) are getting a bit confused

The naming convension is the same as in the v2.54/v2.55 releases (namely v2.56 alpha -> beta -> RC -> stable). Note there is no stable v2.56 yet. Reading the next line i see why you are proposing this:

and not fully apreciating the major improvements and changes going on behind the scenes.

May i ask why not? Which changes don't you like?

[Fizick]

I always wondered, why Avisynth (alpha, beta, and so on) versions is not numbered with a fourth number, as 2.5.6.1, 2.5.6.2 and so on.
Why use this "May5" word?
For example, the first 2.5.6 alpha was in the fact the 2.5.5.1.
May be we need in two brach. One is stable, with some bug fix only added, and new experimental, with new features (i do not mention the mythological 3.0).
For example, the "stable" 2.5.5 has many bugs, at least some of them may be fixed without addition new experimental features.
All IMHO, of course.

[Si]

May i ask why not? Which changes don't you like?

as I said

As an innocent bystander

This is just an observation based on posts that I thought might clarify what's currently happening to the development of Avisynth 2.5.

I personally just run an old 2.5 version that works for me ( I run VirtualDub 1.4.13 for the same reason) but some people will load the latest release thinking its a runner when it could be an alpha

I'm old

And I believe my idea has close to zero cost in terms of time and effort

(I like Fizick's idea about stable and development but that takes effort and most programmers like coding and not organising )

regards
Simon

[Wilbert]

(I like Fizick's idea about stable and development but that takes effort and most programmers like coding and not organising.)

Ok, good points. I think it's good to discuss this. What about the following naming convention?

v2.5.6 <- stable (bugfix only) releases
v2.5.7
...

v2.6.a1 <- alpha releases
...
v2.6.a4
...
v2.6.b1 <- beta releases
...
v2.6.b4
...
v2.6.rc1 <- release candidates
v2.6.rc2
...
v2.6.0 <- stable (bugfix only) releases
v2.6.1
...

v2.7.a1 <- alpha releases
...
v2.7.a4
...
v2.7.b1 <- beta releases
...
v2.7.b4
...
v2.7.rc1 <- release candidates
v2.7.rc2
...
v2.7.0 <- stable (bugfix only) releases
v2.7.1
...

v2.8.a1 <- alpha releases
...

Other proposals?

[mg262]

May i ask why not? Which changes don't you like?

This reads to me as if you two are talking at cross purposes... at least, I read 'appreciate = understand/follow' rather than 'appreciate = like'. But that might just be me misreading it.

@Si: If that is what you meant, I'd have to agree... it can (through no one's fault) get a bit overwhelming trying to follow the changes. E.g. I was very interested in the question of what was happening to chroma pitch alignment, but the volume of posts on that just became too high for me to keep up with.

As for the issue of numbering, I'm pretty agnostic... the 'pre-releases' signalled beta to me pretty clearly, but your scheme looks pretty good, Wilbert. The only thing is that IMO if it is adopted it would be a good idea to signal somewhere *very unmissable* that the third digit was strictly a 'bug fix' number, and hence that it was generally a good idea to upgrade e.g. 2.7.2->2.7.3, but that there might be sensible reasons for not immediately jumping 2.7.x->2.8 .

[Wilbert]

This reads to me as if you two are talking at cross purposes... at least, I read 'appreciate = understand/follow' rather than 'appreciate = like'. But that might just be me misreading it.

Oh. I thought he meant 'appreciate = like'. Sorry, I completely misunderstood it

mg262, i agree with your last comment.

[Fizick]

I do not know why to change "avisynth 2.5" name.
But I like right click to avisynth.dll to check version number (in miscrosoft format), similar to 2.5.6.3 (or 2.5.7 in new suggested numbering) ,
but without any "a" or "b" - only digits is valid symbols there.

so, 2.8.a1 is not valid. May be so:

2.8.0 (alpha)
2.8.1 (alpha)
2.8.2 (beta)
2.8.3 (beta)
2.8.4 (rc)
2.8.5 (rc)
2.8.6 (release)
2.8.7 (bugfix)


or in old (current) numbering:
2.5.8.0 (alpha)
2.5.8.1 (alpha)
...
2.5.8.2 (beta)
2.5.8.3 (beta)
..
2.5.8.4 (rc)
2.5.8.5 (rc)
..
2.5.8.6 (release)
2.5.8.7 (bugfix)
..


But i think it is not very important problem

[IanB]

The issue here is time. Volunteer time.

For example, when reviewing a module I see a bug in a routine, I fix it, I continue reviewing the module, I now see an easy or obvious improvement, I refactor the code. Now I have a new version of a module with 1 fix and 1 improvement. I run it thru the test mill, fix whatever is still broken and eventually check it back into CVS and update the change list and documentation, i.e the paper work. If I were to maintain a bugfix 2.5.5 version and a development 2.5.6 version, I double the grind part of the job, both versions do need testing. I like the programming bit, the grind part I am not so keen on, I do the grind because, to not do so would be unprofessional and I do have a level of pride in my work, but remember this my time!

Okay next example, reviewing the code, find a bug, decide the code is beyond help, I euthanase the existing code and rewrite it from scratch using some 2.5.6 enhancements along the way. Now what happens with the bugfix 2.5.5, does it now inherit the new features needed to get the bug fix. Where do you draw the line on how radical the new feature is allow to be to not get a bugfix. Would you accept Chroma Priority Alignment as a feature to get a bugfix?

As I said it all about time, my time.

That said I do take the point that 2.5.6 has been developing for way to long and we do deserve another stable release on the books. I have a few outstanding fixes to include and some features that I will now defer and then we can start down release candidate path.

All non-volunteers take 1 step back, quick Wilbert help me conscript all the people still standing on the line.

Ramblings from one of the guys doing the work,
IanB

[tsp]

maybe if someone made the ultimative torture script thas uses all/most of the filters in avisynth in insane combinations to stresstest avisynth. Although I think Dideé and mf come close to this ultimative filters it could be inproved.

[Si]

@IanB

As I said it all about time, my time.

As I knew it was

So going back to my original idea - how about just bumping the version and labelling it an alpha (in bold) until the dust settles

(And leave an old 2.5.5 version lying around prominantly as the "stable" version maybe )

regards

[IanB]

Si,

Having just reread this thread and read the change list and compared it to other 2.5 releases and I am now a little confused. The number of additions and changes are about the same as other 2.5.x versions and bug fixes are up about 50%. None of the current changes I see as very dramatic (well maybe the chroma alignment, but I am pulling that as the default from 2.5.6) So I am a little unsure why you think it warrents being called 2.7.x?

If I was doing a 2.7 series of Avisynth it would have significant changes like extra colour space support that would effect the pluggin interface. Now advances like the MultiThreading initiative by TSP I can see may be worthy of being called 2.6.x. But nothing I have added so far I consider that evolutionary.

IanB

[Si]

Never mind me

Carry on the the good work

regards
Simon