excellent illustration how fucked up your communication with your users (actually paying clients) has been and still is.
you can explain what’s fixed but you don’t unless you are challenged repeatedly in the forums. Why? Why do we have to pull your teeth? What’s the problem to have normal change log that explains what was fixed?
7.2.1 stable released, but “has nothing to do” with 7.2 release. It’s not big deal, not urgent fix, but we decided to make release just for it. Yeah, you totally sound like you know what you are doing.
Your 7th release has been long-running shit show, get you act together, hire professional release/project manager.
To be fair most changes are described in the changelogs. The problem is specific verbosity. In the case of filesystem and data integrity issues, there happens to be a particular bug which stands out like a sore thumb (config loss on update), and with such a changelog the end user doesn’t know if the changelogs is referring to that issue or another issue. That’s where it can be frustrating. Or new V6 release missing The Dude and a week later nobody from Mikrotik has given an explanation for this despite several posts of alarm and confusion on their very own release thread? It’s not like Mikrotik staff aren’t browsing this forum, so yes that does seem very strange
Please show us examples of detailed changelogs with descriptions of rare occasions of the issues?
I looked, but I can’t find changelogs with more than 8-9 words per change.
I’m genuinely curious how we could improve our changelog, if you have good examples, please share and we will learn
well, as helpful as I’ve seen you around when discussing release process.
You don’t have better description internally than “happens on very rare occurrences”? Is this what you are telling us?
The risk evaluation for the bugfix was “happens very rarely therefore totally makes sense to be released as i minor version”? Seriously? Minor release with one very rare bug you wouldn’t bother elaborating on?
And then someone else from the team spits the beans and gives us little more detail which you obviously possessed but did not bother to share with us. Because? “It’s not a blog”.
I have suggested before that instead of this changelog you create a database with all changes (with version number of change, version where issue was introduced that it fixes, version where change becomes irrelevant, etc. as database keys) and then each item contains both a 8-9 word line and a more detailed description when that is warranted. Also include a pointer to documentation when relevant.
Then the opening posts of these topics can be replaced by a URL on a server that queries that database and returns the changes in that version, and users can click on links (or hover above an item) when they want more detail or want to find the info relevant to the change in the documentation site.
Also, when “system->packages->check for updates” is used the displayed list of changes can be the changes between the currently installed version and the proposed new version, instead of only the changes between the last and before-last version.
After the initial implementation it will probably mean a reduction of work, because the specific changelog no longer has to be prepared (changes are inserted in the database individually and get a version number once they are committed into some release) and because there will not be so many questions asking for more detailed explanation.
it’s called bug tracking system (which you probably know already). which they maybe don’t use internally, or use and it has extremely poor content quality, or use, fill in properly but refuse to share with their customers.
Being altruistic person I want to believe that MT has a very streamlined process of change tracking. However, ROS being closed source, perhaps information in their change tracking system might be too verbose to be open to public, perhaps it would expose too much details.
Of course we have a bug tracking system, internal testing procedures and it’s all linked with customer reports. A lot of reports are misconfiguration and turn out to be false. A lot of bugs are caused by other bugs, nothing is as straight forward as you seem to think. One improvement in some drivers can cause a ton of related effects in other tools. We rather spend time on bug fixes, than on very detailed changelogs. Just keep using the latest version and you will be fine
I don’t think it is called a bug tracking system. It is more likely to be called a release tracking system.
It may be part of a versioning system for the sourcecode. You do a “pull request”, implement or fix something, submit the new stuff or patches, together with a description of what you fixed and how that affects the use of the system (new feature, new parameter etc), and at some point it gets accepted and makes its way into a new release.
At that point, the description of your fix goes in the changelog.
Of course the degree of automation can vary. But it is not like it is coming for free now, someone has to compile that changelog and for the usual release with some 20 items on there that is work too.
this description of a change can sometimes be as simple as “fixed typo” and then we have to come up with all potential issues this could have fixed. not everything is as perfect in the real development world
With the risk of being banned, this answer is 90% BS. I don’t think anything is straightforward, I’ve been in the software business for 25 years, building and operating business critical systems for bluechip as well as unicorn clients. I’ve struggled with bugs, features, processes and demanding customers and CEOs. Your team is lacking basic transparency and your attitude is absolutely unacceptable for senior support person in 2022. It would’ve been unacceptable 10y ago too. That’s the obvious deficiency. You (personally and the team) are absolutely incapable of building trust with your clients and are in fact doing exactly the opposite. I love MT hardware, I’m very comfortable with winbox, but I absolutely dread your releases. Your QA is BAD therefore I upgrade my MT boxes only when desperate or adventurous. You are reading the forums and you know I’m not alone.
Apart from this, I see tons of other clues that match the pattern of projects with totally messed up organization. I’m confident you are (or have been until recently) on death march.
But yeah, act dismissive, we are whiners I guess. Feed us BS and act victim. Doing so you are ignoring the fact that most of us would migrate away the first moment we see alternative. All this “noise” is (a) because we don’t want to migrate yet (b) we care about what we use.
Dude, stop drinking vinegar. You don’t have to use MT. The big companies do the same stuff and they won’t give you an answer on a forum. So be grateful that they tell you in more details what is wrong. Some use more words than others, so be it. And I won’t go to the pre-production testing before you roll something out in the field.
And about the bitching of V7. MT made a mistake to announce a release. Then came the unicorn jokes and so on. But most of the stuff that was intended for V7 made it in V6.
The same stuf happened with the container release. Not a too smart move, but alas…By the way: Price / performance is great.
Eh. Vinegar or no vinegar, it’s good that people speak the unspoken that exists in many of our minds on some level sometimes. A bit of negative critique is usually a good thing (and credit to MikroTik for keeping such platforms open and, as you say, even interacting with their users on a public-facing forum), as useful elements can definitely be extracted from such feedback also. Price / performance is great, yes, but having 1 in every 5-10 routers pack up on you while running a routine upgrade AFTER a patch is released specifically to address alleged filesystem improvements, does rub off as almost insulting to the end user with all due respect as well (especially when it seems to hit a different router each new release and you’re supposed to swallow the claim that this is a “very rare occurrence”). So it’s a two way street no doubt, and both sides need to play the game right or else it’s inevitable that toys will be thrown out of the cot at some point. Personally I’ll be sticking it out and staying with MikroTik despite the turbulence in v7’s early release days, because I know the headaches & kinks will be ironed out soon and v7 will turn out be the best version of RouterOS yet and an (indispensable) pleasure of a platform to deal with and integral part of our arsenal as network admins
you have problems with reading comprehension? or you have nothing useful to say so reverting to passive-aggressive provocative behavior? bullying your customers, not the first time I see you doing that.
I doubt v7 will be smooth sailing. There’s zero evidence the team learned from their mistakes. And the could’ve avoided most of these mistakes by just looking around, internet is full of books, articles and presentations on the topics of release management, 2nd system effect, whatnot. They are doing decade(s) old mistakes and not learning from them. Then act arrogant when called out for it.
Calm down please.
Lets keep it constructive and not abusive.
You have a point but things are not always that easy.
We get a lot of value for the money but that comes with some downsides, learn to accept that.
