|
|
Post by Robert on Jan 22, 2024 16:16:31 GMT -5
With the availability of SPFLite beta 24.021, I started looking around to see the impact of this beta release, and looking at the General Options GUI, I noticed the entry Check For SPFLite Update Interval. When I did a manual check, it said I was up to date, and when I checked the last prod release 23.313, it said the same thing.
What I am wondering about is whether we could be more precise about this checking process.
First, is it possible for the code to "know" if it's a beta release? If you look at the Title Bar, all the current beta says is, SPFLite(v3.0.24021)
If this were a production release that had been made on that same date, you'd see exactly the same thing. I wish this worked a little differently. How so?
(a) Devise a means by which your code "knows" if it's a beta version or not.
(b) In the Windows Title Bar, add "BETA" to it, so it's clear that a beta is running. Like this: SPFLite BETA(v3.0.24021)
Second, when a user clicks on the Check Now button, you would check both for the most recent prod version and the most recent beta, and report on both statuses. Now, sometime when you release prod, you don't always show a download link for betas, since the prod would be newer than any existing beta. How you would handle that is up to you. Do you have a way to download "old" beta? I don't recall ever trying to do that, but hey, maybe someone would want to for some reason?
Well, that's the idea. Since you are so close to a new prod release, I wouldn't hold it up just for this, but maybe it's something you could look into for the future.
R
|
|
|
|
Post by George on Jan 22, 2024 16:39:20 GMT -5
Robert: The beta versions are transient. They exist while they exist, and then they're gone. I don't want to change that. I really don't want to make putting out a new release, either Beta or Full, more complicated.
I'm not sure just how benefical any of this would be as we have no idea how many people even download and try out the Beta versions. We certainly don't get a lot of feedback.
It's our old problem, lack of user involvement.
George
|
|
|
|
Post by Robert on Jan 22, 2024 16:44:14 GMT -5
Well, the only thing is, your current advise is to download the beta in the prod directory. Depending on how people run them, there could be some confusion. Yes, betas are transient, and I don't want to overly complicate this. You have enough problems. But, what about the first part? Can you identify an SPFLite exe as "BETA" and show it on the Title bar?
R
|
|
|
|
Post by George on Jan 22, 2024 16:57:00 GMT -5
Robert: The problem is simply source maintenance. It's just making sure the (8 different source lines) are altered properly between Beta and Production versions. And yes, there are 8 different variations of the Title Bar text.
Sure I can make it simpler, but really, is this needed?
George
|
|
|
|
Post by Robert on Jan 22, 2024 17:05:10 GMT -5
Not if you have to change something 8 times. If it were me, I'd conditionally #include the string(s) involved, but you have made this elaborate enough that it means this is the end of the story.
|
|
|
|
Post by George on Jan 23, 2024 9:10:31 GMT -5
OK, done.
George
|
|
|
|
Post by Robert on Jan 23, 2024 11:34:26 GMT -5
Just checked out 24.023, it looks fine. (I thought for sure you decided against it.)
R
|
|
|
|
Post by George on Jan 23, 2024 13:42:30 GMT -5
Robert: It's not that it's difficult, but it's yet another checklist item for the 'push-out-a-release' process, which is already 4 pages long.
George
|
|
|
|
Post by Robert on Jan 23, 2024 23:25:07 GMT -5
George,
Since you posted the above 9 hours ago, I have been thinking about your release process, that 4-page document. Have you ever considered a "build script"? Unix developers have long used a "make" script and the Unix "make" utility to create builds. If you could use or adapt a make-like strategy, it might simplify your build process. Sometimes people create their own home-grown build systems, when an off-the-shelf "make" utility doesn't suit their needs.
Imagine your 4-page document. Now, think about what it would take to automate each step of the process. Suppose you could write some kind of automation tools, and put them into a script of some kind. There might have to be "exit points" where you had to do some steps manually and there was no good way to automate them. But, suppose even SOME of your process could be automated. If so, that could take a lot of the pain out producing new releases.
I don't know your internal workload, so this is just wild-@$$ guessing here, but I have always been a big fan of automation. Yes, you might have to write some of your own tools, and that would be work, but the effort would be WELL worth if, if you could pull it off. AND, you certainly have an incentive to make it work, because when you were done, it would reduce your work on a long-term basis, and it would help remove points where things might go wrong if you ever forgot something.
Just a thought.
R
|
|
|
|
Post by George on Jan 24, 2024 11:57:35 GMT -5
Robert: Sorry, not practical. Have a look at \SPFLite2\$Install Guide.doc, read through it and you'll see why.
The problem just isn't a matter of making some build/make/script thingy. It's all the other stuff intermixed into it.
George
|
|
|
|
Post by mueh on Feb 7, 2024 4:45:46 GMT -5
George: With Beta version in Title a second start doesn't detect the current running SPFLite in InitSeeUnique Function and creates another SPFLite Process .
Adding the $BETA string to Title in InitSeeUnique might give some incompatibility if non Beta is active but i can live with it since
checking for both Beta and non Beta for non DEFAULT Instance is some overhead .
Thanks
|
|
|
|
Post by George on Feb 7, 2024 9:50:26 GMT -5
MUEH: There's always an interaction you don't think of.
Fixed.
George
|
|
