I am genuinely interested in understanding the significance of a milestone in this context. A couple of years ago, I reported bug #66469 , and it was promptly acknowledged as a bug, which I found promising. It was then assigned to the milestone “Xojo 2022r2.” Wonderful, I was Pro Plus at the time and I figured it would be fixed.
While I fully appreciate the challenges in scheduling bug fixes, but I’ve noticed that the milestone for this bug has been changed repeatedly over the last seven versions, as indicated in the bug report:
Paul Lefebvre changed the milestone to %Xojo 2022r2 1 year ago.
Javier Menendez changed the milestone to %Xojo 2022r3 1 year ago.
Travis Hill changed the milestone to %Xojo 2022r4 1 year ago.
Travis Hill changed the milestone to %Xojo 2023rl 10 months ago.
Travis Hill changed the milestone to %Xojo 2023r2 6 months ago.
Travis Hill changed the milestone to %Xojo 2023r3 2 months ago.
Travis Hill changed the milestone to %Xojo 2023r4 14 minutes ago.
I’m genuinely curious about what a milestone represents in terms of priority and commitment. Moreover, I’m interested in how I can assess whether it would be appropriate to allocate our own resources to address these bugs or find workarounds.
While I understand that a delay of one or two milestones can occur, seven consecutive changes raise questions, and I’d appreciate some clarity on this matter.
I can’t tell you how many times this has bitten me over the years. Sadly, there’s a workaround, so I wouldn’t hold your breath while you wait. Why it keeps getting rescheduled is beyond me.
Well, the problem is maybe that this is so transparent.
But for a new release the Xojo team schedules what cases they want to do in the release.
Then they work on the cases for the release. Some cases finish in time and go in the release.
Other cases take longer and may slip into a future release.
When a release is decided to ship, all non-finished cases are moved forward to a future milestone.
So basically this is just some organization stuff for the Xojo’s release planning.
And don’t get too excited if something is scheduled for a release as it may not happen.
I don’t know if we will get an official response or not, but @Jay_Menna’s question is reasonable. However, derailing the thread like this will guarantee no response.
It is just the desired version in which the fix is intended to be released…
Usually bugs can sit there for years without updates, maybe the “Fast Fixes” of the Pro Plus just means that the bug will have updates every release…
Even if you get an “oficial” answer, I think that your own experience is more than enought to determine the value of a milestone or more important, the value of the the “Fast Fixes”
Thank you very much for your kind and thoughtful response.
However, I believe that you might not have more knowledge on this topic than many of us. I was hoping for an explanation directly from Xojo Inc., rather than speculation. I apologize if this comes across as rude, but I’m unsure about the value of speculation without an actual explanation from those who work with it daily.
Well, if anyone looks what is in the issues database for e.g. MilesStone = Xojo 2023r2, you find 267 closed issues, which got the milestone and being fixed/implemented.
You may see that lots of this issues got reported, later assigned a milestone and then worked on. e.g. case 72955 got reported, a sample project, than assigned to Javier, put on his plate for 2023r2, then fixed by him a few weeks later and shipped in the release.
It’s always bad for us if our personal cases sit there for a long time, but quite a few cases get addressed every release.
Normally, cases having a milestone will be those we’ll be implementing or fixing in that milestone. I think that’s what usually happens.
Sometimes a case can get stuck (i.e. It’s a feature that has another task dependency, it needs more research, it’s too risky to implement at the current release cycle, you’ve been working on another case that had higher priority, …)
That doesn’t means we aren’t working on it. Depending on the case, sometimes we commit changes that doesn’t completely fixes what the case describes, but at least it reduces the problem (for example, #69774 got a partial fix already, but it’s still open), or adds part of the required functionality.
Some examples of issues reported a while ago that missed several milestones, but they were eventually fixed in 2023r3:
Seems to me it doesn’t represent anything at all, except a vague idea that the issue could be looked at in the release cycle mentioned. But that doesn’t mean it will be worked on.
It is though. Xojo customers have become so comfortable with the transparency into their operations that when just a little is taken back, there is a collective temper-tantrum. I experienced that several times as an engineer when we made internal changes to make processes better, which resulted in certain data points being less readily available.
The bottom line is that giving customers the ability to see which release that individual little issues are being worked on usually causes disappointment and hostility towards the company because people take that as a promise, when in reality it’s just a “We are going to work on this case during the 2023r3 cycle, even though it may or may not be ultimately included in the release.”
These conversations are interesting. And I can certainly understand your frustration at having to deal with customers, but my origin question still remains unanswered:
Can you tell me what a milestone is? What does it mean? Of what value is it to me?
“We are going to work on this case during the 2023r3” is not the case if it is kicked down the road 7 times.
It’s less for us users, and more for the engineers internally. It’s just that it’s exposed to us, currently, in GitLab. Sometimes it’s of some value to us to see it, often it’s not. Until something is in testing for a particular release, we won’t know for sure whether it’s made it into that release.
