Maybe you are being overly sensitive. It’s not like I’m trying to sue MDG for the lost productivity and inconvenience.
Running a business that serves thousands of people (whether they pay for it or not) requires accepting all feedback, including criticism and complaints. It is such feedback that helps the business gauge what to focus on and prioritize and learn of other perspectives and new ideas. I think MDG understands this, after having heard many complaints of other issues with Meteor in the recent past (and even now after the loss of free hosting announcement).
Just because something is provided for free it doesn’t mean that users should accept low standards of professionalism. Can you imagine the kind of “feedback” Facebook, WhatsApp, Gmail, Twitter would get if such services stopped working properly, even though most users, even heavy users, don’t pay anything to use them?
A dead-on-arrival case of a release candidate should not be taken lightly, and if I had been responsible for such an unprofessional and embarrassing mistake I would fix it very quickly (e.g. within 24h) with highest priority.
Anyway, I will wait patiently for the fix and then resume productive work on my app once rc.3 is out.
Sorry to say ask this but isn’t it also a bit unprofessional and low of standard to work with an unofficial RC to do productive work? Just saying… if you’re working with something that’s work in progress, things are going to break eventually. I’m not saying this break should be accepted but at the end of the day, these things happen. I’ve seen major breaks being found in other open source RCs once they roll out to more people/more people start installing them.
Not to incite a riot or anything, but I’d just like to point out that many of us are paying customers if we are using Galaxy. As for an RC not working for everyone; meh. It’s a bug, in a release candidate, that will be fixed before release, isn’t that kinda the point!?
Am I wrong to consider rc.2 as an “official” MDG release? I thought if it’s listed in GitHub in the “Releases” tab of meteor/meteor account, then it’s “official”: https://github.com/meteor/meteor/releases
So I’m curious to know why you refer to rc.2 as an “unofficial” release candidate, and what would make it an “official” release candidate.
If it was released by someone outside of MDG or not yet listed on that Releases page, then I would call it “unofficial” and wouldn’t have had my expectations as high.
I don’t think the fact that Meteor is “open source” is relevant to whether our expectations should be lowered, because the people working on Meteor are paid MDG employees who have been specially selected out of numerous candidates for their high level of skills and/or experience, so it wouldn’t be the same as if contributions had come from a large pool of volunteer developers with skills varying widely among the pool.
Microsoft’s .NET framework is open source. As an experienced .NET developer, I haven’t come across a .NET RC version that couldn’t start at all.
Sorry, unofficial RC was the wrong wording. With unofficial I was referring to “This is not a release intended for production use.” So I don’t get the zealous hate tirade. As Siyfion pointed out: That’s the point of a beta/release candidates. To get feedback from users and find more bugs.
Now, I’m not even sure which bug you’re referring to, there’s probably more than one. I’m sure some bugs could have and should have been prevented. But at the end of the day, if you choose to go with a non-stable release like I pointed out, things tend to be broken somewhere. And you must be a robot apparently since you haven’t seen things break anywhere. Especially Microsoft totally never breaks anything … like … Azure servers in an entire region for a day. Things like that. Never. Happen.
Maybe you had misinterpreted my use of the word “productive”, as it did not mean that I will use it in production environment. “productive” simply means producing output, i.e doing real work to create value.
Maybe you should have found out before writing as it’s no minor bug, but a complete showstopper for many people (all Windows users it appears):
It was reported 9 days ago but only officially acknowledged by benjamn 9h ago, and based on GitHub there’s still no one assigned to it.
I know, which is why I avoided the beta releases under 10. But I’d expect an RC release to at least run instead of crash on load, as it is meant to be a candidate for final release. It’s just logical to expect an RC release to be more stable than a beta release.
I never stated anything like “Microsoft totally never breaks anything”.
I don’t think the semantic discussions of the meaning of ‘release candidate’ or a release candidate’s suitability for production (clue: it is not suitable for production) really fit this.
Any chance you could take them to another thread as it was useful to be able to follow this one and see what’s actually going on with the release.
It would be nice if the change list would be added to every tag/release, instead of somewhere in a comment on a ticket in GitHub. Like this for example:
@benjamn does a good job in providing the details every time, but a central place would be nice. This is how he does it in certain threads:
I guess there’s a fine line there. You’re paying for Galaxy, not Meteor, and while a Galaxy customer has every right to complain about something not working up to standard, I’m not sure if they have a right to make demands of Meteor. I see the two as two separate things, even though they’re related.
But regardless of any of this, I hope we can all agree that there’s a respectful way to encourage the team to focus on something, rather than making demands.
Yes. But the information flow being very sparse is not something that should fall under “shit happens”.
And I find this creative redefining of the words “alpha”, “beta” and “release candidate” to be somewhat weird.
Alpha: Not feature complete, somewhat working, buggy.
Beta: Largely feature complete, still buggy
RC: Feature complete, without major bugs
A progression from a beta with a showstopper bug to an RC should not happen. Because if everyone gets to redefine what those words mean then we can not rely on anything to have meaning. As shown in this thread where people questioned the RC status. If you simply adhere to the accustomed names of versions then you would not have this discussion in the first place.
I’m still in the process of publishing the 1.3-rc.3 version of the meteor-tool package for Windows, so I don’t think meteor update --release 1.3-rc.3 will work just yet on Windows, but I’m working on that now. I’ll announce it when I know it works on all platforms (unlike last time).
Edit: The error I got from meteor publish appears to have happened after the meteor-tool package was successfully published, so I believe 1.3-rc.3 is now available for all platforms!
?
