Scheduled releases of Everything.

[ChrisGreaves]

I would like to discuss the possibility of releasing Everything on a shorter period than we have right now.
This is not a criticism of Everything; I am now of the conclusion that Everything is evolving faster than I can learn its power.
The current alpha version is two years older than the current release (1.4.1.1024)

This situation suggests that the community will go on testing 1.5a until when?
I see no major problem in freezing the development of new features while quick-fixes for 1.5a bugs are hurried out of the door, and most of us settle into a new version.

Today the new version (1.5.0.1351a) seems to be pretty robust. There will always be small problems when software is in an accelerated state of development, like the galaxies flying apart at ever-increasing speeds. That will not change.

But if 1.5 became the standard, we stand a chance of convincing stalwart 1.4 users to migrate to 1.5. They will benefit from improved power; we all will benefit from a larger population "testing" 1.5.

David cannot be faulted for responding to questions, problems, and suggestions.
Switching to a new release every six? months should reduce David's range of work to be, in the main, in the realm of one version (1.5) rather than two versions (today 1.4 and 1.5).

If switching to a twice-a-year release results in a two-week hiatus in fixes and responses, so be it. I think that Everything will be all the stronger for it.

Cheers, Chris

[Thy Grand Voidinesss]

I also do not understand why a sole developer of this program is splitting his valuable time between the 1.4 and 1.5 version, when that latter one has been working quite nicely for a long time now

And, considering how its GUI was reworked, why it should not be labeled 2.0 instead of 1.5

[ChrisGreaves]

I also do not understand why a sole developer of this program is splitting his valuable time between the 1.4 and 1.5 version, when that latter one has been working quite nicely for a long time now. And, considering how its GUI was reworked, why it should not be labeled 2.0 instead of 1.5

Hi.
I was steering towards the idea that regardless of what was going on in the world, a discrete identified milestone might be a good thing.
For example, as an example only:-
1.4 ---> 1.5 major enhancements
1.5 ---> 1.6 mammoth set of bug fixes
1.6 ---> 1.7 emptied the ToDo list
1.8 ---> 1.9 major enhancements
1.9 ---> 2.0 mammoth set of bug fixes
2.0 ---> 2.1 emptied the ToDo list
and so on.
In this example (example only!) Everything cycles through three phases "Enhancements, Bug fixes, ToDo list")
I am not suggesting that a release be identified only as a bug fix, or enhancements, but ask that we consider the impact of any separation, of which this is just an example.
(a) Those of us who enjoy being on the bleeding edge get to surf on the weekly? releases
(b) Those of us who absolutely must have a bug fix can grab hold of the version that fixes their bug, and then ride it as stable version until their next major problem with Everything is released.
(c) Those who are waiting for an enhancement likewise can pounce on that when it comes out and then make it their stable version.
(d) Those in a commercial or production environment (not me any more!) can implement each "bug fix" release as it comes out and avoid management's perceived risk of "development" versions
and so on.

I don't know how David manages his time; I couldn't keep up his pace, but I do know of the satisfaction of setting to work on a specific problem in the garden, in the house, or in the shed, and seeing it completed; "rolled out the door". I have seven rooms in my home, and assigning one day of the week for cleaning the scheduled room was one of the smartest things I did when I moved in!
Cheers, Chris

[NotNull]

Before giving my opinion, some facts first:

Since the first public relaese of Everything 1.5 (2021-03-13) there were 115 releases, in a period of 120 weeks; about 1 release per week.

In that same 120 weeks, there were 17 new Everything 1.4 versions released, most of them critical updates.
So most (if not all) new features end up in 1.5, while 1.4 is in "maintenance mode".
(end of facts)


My interpretation of the 1.5 relaese schedule is that currently @void works steadily on the new features and when a (semi-) critical bug is found, that bug gets fixed and all features that are ready at that point get released with that same update.
Seems like a sensible strategy to prevent maintaining multiple versions at the same time (which there probably are anyway), but is a-typical.

Typically, an alpha version is for introducing features without paying too much attention to bugs; alpha versions are therefor not suitable as a daily driver.
(Beta versions are for fixing the bugs and when most/all bugs are fixed, it will go to production (after test/acceptance phase).)
There are other software development methodologies, but none matches 100% the Everything development method (maybe he should add his method to the wiki ). At least from my point of view from the outside.

Point is: there are no laws against that. These methods are used in companies, where people working together have to find a modus operandi. Being a "free range developer" has its perks.
(that should probably be "free rein developer", but I like the mental image of a "free range developer" )

Beside perks, there are downsides too. In a company you have to work with deadlines and requirements. Without those, things are never finished.
That goes for paintings, books and any other creative work. There is always something to add, to improve or to polish.
The one time I did something that by a far stretch could be called software development [1], I felt that too (waking up in the middle of the night with yet another "brilliant" idea ..).


For now, void keeps releasing new features and fixes at an insane pace and yet .. the to-do list keeps growing evne faster ...

If *I* had to handle this amount of work, I would:

• Take a good look at the to-do list
• Decide which features *absolutely* need to be in 1.5
• Cut that list in half (!!)
• Work on those features (and probably let a couple of smaller features sneak in too )
• Put problematic features on the other half of the list and add a new one from "the other half".
• When finished, release version 1.5.1 as beta
• Dedicate a couple of weeks on just fixes for 1.5.1
• Write the SDK
• Promote 1.5.1 to stable.
• Update the support pages for 1.5
• Start working on version 1.5.2 (or 1.6) for the other half of the absolutely needed 1.5 features.

But to be honest, 1.5 now already contains so many nice new features, I would probably wrap it up and call the current state 1.5.
So maybe it is better not to listen to me


[1] Writing the toolkit to migrate users, mailboxes, data, access rights, settings, etc, etc) from a Unix-based network OS to a Windows based network OS.

[therube]

1.4 is a Release.
1.5 is not.

So even though 1.5 is so much better then 1.4 (it is), an individual then decides if the features it has is of value to them - enough so, to switch to 1.5 alpha (with whatever that may mean).

Simple, as I see it.

[NotNull]

1.4 is a Release.
1.5 is not.

That does not make sense. One can release an alpha version, a beta version or whatever version.

[ChrisGreaves]

But to be honest, 1.5 now already contains so many nice new features, I would probably wrap it up and call the current state 1.5. So maybe it is better not to listen to me

You gonna change your moniker to "Shrinkin' Violet?"
Not Null, anyone who makes sense - or even tries to - is worth my ear for a minute or two. My feeling too is that two years is long enough to alpha-test a version.
Still I will maintain that I am not privy to David's work methods.

I know that I feel that "an issue is under control" if I have recorded it in a list for a project (WhatFAQ.doc) but my neighbour will ignore any interruption at all until he has finished installing a 4'x6' window. Different ways of working.
I know too that some changes that a client requests look small, but if they change the philosophy of a design, they amount to a mammoth consumption of time.

Anyway, I am glad we (all) can have this discussion.
Cheers, Chris

[ChrisGreaves]

1.4 is a Release. 1.5 is not.

Hello therube. I think that that echoes my point, that "1.5" has not been released as a stable version.
Of course, as long as release is delayed until all the new (requested) features are coded means that, with Everything, 1.5 can never be released, right?
Cheers, Chris

[void]

Thank you for the feedback and suggestions everyone.

My intentions for the Everything 1.5 alpha is to show that I am still working on Everything.
I would rather have this experimental 1.5 alpha than have nothing to show for years.
The previous Everything versions were also in alpha for years. (1.4 was in alpha/beta for 3 years)

I am working on Everything 1.5 full time.

There's a few more things that I have to do (it's a short list) before 1.5 moves to a beta release.

Sorry it is taking so long and thank you for your patience.

[ChrisGreaves]

... to show that I am still working on Everything.

Thanks Void. I rather suspect that by now everyone on the planet Gsdfghjkl knows how much effort you put into this program.
My intensely private view is that I wish you would slow down so that I can catch up

There's a few more things that I have to do (it's a short list) before 1.5 moves to a beta release.

I am not privy to your mode of work, so I cannot judge. But I do have a question:-
How would it affect you (your product, your schedules, your way of thinking/working) if you switched to a alpha/beta/production release every {say} six months?
I suspect that a production release (not alpha, not beta) is associated with a tremendous load of documentation to make the re;ease independent, and that takes time away from programming.

Based on your comment above, a published version release every {say} six months would be a visible signal that you are still working.

Further, even if you just went on for another 62,956 days (to 19-Nov 2095) we would have to trip over from 1.5.9999 to 1.6.0000


Cheers, and many thanks
Chris

[NotNull]

Sorry it is taking so long and thank you for your patience.

It is not taking long at all ! Everything keeps progressing at the speed of light (I can't keep up either; still on 1347a as I like to test the new features/fixes)

I think both ChrisGreaves and I are looking for ways to make your life a bit easier. That was the intention of my post anyway.

[void]

Thank you for your help and support.
I couldn't ask for more.

I wouldn't be able to work on Everything without you.

[ChrisGreaves]

I think both ChrisGreaves and I are looking for ways to make your life a bit easier. That was the intention of my post anyway.

Agreed!
But that's why I was asking for a discussion.
I am in no position to advise.
Sideline: I suspect too that a shorter-periodic release would give you a satisfying milestone.
Again, my view is that the way your are going you will never run out of suggestions, and hence you will never run out of enhancements, and hence you will never stop working.
I can see that a change in version number (e.g. 1.5 to 1.6) involves much overhead. That view leads to a counter-argument that one should just go ion releasing 4-digit builds to 1.5a.

In the end I suppose that each user will have a different measure of what makes any build Stable for them. Since I have no professional or production cases resting on Everything, to me every build is Stable!
Cheers, Chris

[therube]

release every {say} six months?

Mozilla has gone to a (has been on a) "Rapid Release" schedule for FF (& TB), & that does just wonders for quality & stability .

Let me correct that, "Mozilla has gone to a "Rabid Release" schedule & FF (& TB) simply suck because of that (& for many more reasons).

One saving grace is that the version number always increment, 115.x now, & (before you know it), 116.x (& then 117.x ... 999.x ...).
(And as 116 > 115 > 114, cough, cough, cough, choke.
And, it allows FF to keep up with Chrome's numbering [increases] .)


I commented the other day:
> amazing how consistent the UI has remained all these years (& that's good, IMO)
(comparing SeaMonkey 1.19, circa 2010, to today's version, 2.53.x)


Related, https://www.dslreports.com/forum/r33707189-.