Jump to content

4.2.7 Release or changelog.


Mopar1973Man

Recommended Posts

What was fixed in this release? 

Quote

4.2.7 is a maintenance release that fixes issues identified in 4.2.6.

This is way too general and wanting to know more of what was fixed in the release. Waiting for the release to occur and wondering if something I submitted was fixed or not you never know because the changelog why very uninformed. :(

So what issues were identified in 4.2.6? 

Why bother list just the date of the release but have no idea what was release for and what was fixed. Kind of like not being able to see the bug list and knowing if this is a common issue already reported so do I submit a ticket because I found a bug? Or did someone else already submit the same bug? Was the bug fixed in this release? You'll never know. :(

Link to comment
Share on other sites

  • Management

It's rather rare for any software vendor to list every little bug fixed. Check out your Windows or Apple OS releases. They certainly don't list what must be hundreds of issues fixed in each release :)

If you are having a specific problem with your site just submit a ticket. We are happy to help. If you are not having any issues then you can safely assume that any fixes in a release do not impact you and there's nothing to worry about.

Link to comment
Share on other sites

Not a Windows fan but a Linux fan... Yes, some companies do list every bug they fix. Make it much easier to jump in and support people that already submitted a bug and give feedback this way.

https://bugs.launchpad.net/ubuntu

But I do understand it just I did submit a bug. It would be nice to see the bug list like in the past. Then you could see resolved or its already be submitted. At the same time I don't want to be caught crying wolf all the time needlessly. 

Link to comment
Share on other sites

No, they certainly don't list what must be hundreds of fixes... But they do at least hit the high points.  There are software development companies that use the likes of JIRA and have public facing feature / bug trackers, regardless of whether or not the public can comment on them, where they can auto-generate release notes.

Your 'Release Notes' section is a bit bi-polar.  There are some releases that AT LEAST have a bulleted list of 5-6 items that were changed / fixed, others with nothing but, 'Maintenance Release go fend for yourself', or just a link to a blog post.  Are you going to use your Release Notes for what they are, are you going to use your Blog, or is it something you're going to let fall by the wayside like documentation?

You've stated numerous times that you intentionally don't have a public bug tracker because you don't want a duplication of effort.  Completely understand, but that's almost exactly what you've created with your Release notes database.  You're either not putting anything in there, or the information exists somewhere else and is being directly linked.  What's the point?

All the Release Notes seems to do is let me down every time I go take a look.  I had to go back to 4.1.17 to find what I would consider quality release notes.  Starting with 4.2, release notes fell off your radar.  

 

Link to comment
Share on other sites

  • Management
52 minutes ago, Aiwa said:

I had to go back to 4.1.17 to find what I would consider quality release notes.

4.1.17 has the exact same thing about bug fixes as 4.2.7 did :)

The only new feature in 4.2.7 was GDPR stuff which we mentioned. We just don't see the value in a list of fixed bugs. As always, if you have a specific issue just submit a support ticket. If you are not experiencing issues then seeing a list of bugs that don't impact you seems like unnecessary noise.

Link to comment
Share on other sites

So, you're saying the only new things added to the 4.2.x branch, not bug fixes or security releases, since the initial 4.2.0 blog announcement are the following? 

Quote

4.2.2

  • A new extraction process to make auto-upgrades more robust
  • The upgrade system will do a check of all files to ensure they are up to date before proceeding

4.2.6

  • RSS feeds now use guest page caching system
  • Analytic tracking code has been moved to inside head tag
  • Ad code placement has a new setting to clarify how sidebar display should be handled
  • Various enhancements to Redis engine including data stored encrypted at rest
  • Search result improvements 

4.2.7

Is that accurate?

Maybe I'm going off topic.. I see the OP was more focused on bug fixes, which is still relevant.  I have had to put in DIRECT work-around code due to more than a handful of IPS bugs.  Some of which have since been fixed, some of which still exists, and some of which I haven't a clue their status.  Last I heard on one of them was the door on T3 slamming shut with a  polite "We'll look into it when we have more time", don't get me wrong here I understand as it was a low priority low visibility low impact but, but still a bug.....  When is more time? Are we talking IPS 5? 

So, as a 3rd party dev, what am I supposed to tell my clients?  When can I take out my work-around code? When can I expect my work-around code to explode because IPS has finally fixed a bug that was reported ages ago?

One small example: 

 

Link to comment
Share on other sites

4 hours ago, Charles said:

It's rather rare for any software vendor to list every little bug fixed. Check out your Windows or Apple OS releases. They certainly don't list what must be hundreds of issues fixed in each release :)

If you are having a specific problem with your site just submit a ticket. We are happy to help. If you are not having any issues then you can safely assume that any fixes in a release do not impact you and there's nothing to worry about.

MacOS and Windows aren't really comparable to forum software, but none the less Microsoft do publish detailed change notes [1] [2].

A more fair comparison IMO would be WordPress, which does appear do provide reasonable change notes [3]. Other platforms also provide change notes, such as NodeBB [4] and Vanilla [5].

When I take my site offline to perform maintenance, users always ask what changes there will be. "Bug fixes" isn't usually enough to satisfy them, but "Fixed several bugs including music being paused when a notification arrives on iOS" would.

Change notes are especially useful when you publish pre-release builds, because they indicate what should be tested.

Link to comment
Share on other sites

The only thing I noticed is that when I went to upgrade there was a list of stuff being changed in the ACP, and I wanted to look at that list again and it wasn’t the same list on the release notes. Doesn’t really matter a ton to me personally, but I seem to recall it mentioned a few more changes than just GDPR and curiosity always gets the best of me. 

Link to comment
Share on other sites

  • Management

If you are having any issues with your community just submit a ticket and we can answer any questions you have about your issue. Sometimes we can resolve it right then and other times we will let you know what release the fix will be in.

Link to comment
Share on other sites

1 hour ago, Charles said:

If you are having any issues with your community just submit a ticket and we can answer any questions you have about your issue. Sometimes we can resolve it right then and other times we will let you know what release the fix will be in.

So, if I have work around code in my apps because of an IPS bug, I can keep submitting tickets asking when it's been fixed? 

?

Link to comment
Share on other sites

I'm always wanting to look at the changelog to see what the updates are going to impact or improve. To find out later a feature has change or setting need to be configured and you didn't know. I'm want to know what bugs are currently happening so I can be aware of the problems with different features of the software. Of course, I was told that my issue should be correct in this release. I'm curious of other issues and bug that might be in the software. Maybe if I'm aware I could help with how my site is configured. Who knows. But knowledge is power and knowing there is an issue give the site owner more power to handle things better. Being that the entire list of bugs is no longer public you saying it's cool to report everything we find wrong with the software? Even though it could of been reported by hundreds of people already?

1 hour ago, Aiwa said:

So, if I have work around code in my apps because of an IPS bug, I can keep submitting tickets asking when it's been fixed? 

Valid point.

3 hours ago, Aiwa said:

Maybe I'm going off topic.. I see the OP was more focused on bug fixes, which is still relevant.

You are fine. I'm agreeing with you... ;)

Link to comment
Share on other sites

10 hours ago, Aiwa said:

So, if I have work around code in my apps because of an IPS bug, I can keep submitting tickets asking when it's been fixed? 

?

I've been submitting tickets for this one bug. Kept getting told I was crazy, eventually got around to replicating it on here and other sites was told it was fixed. But haven't seen it released yet. It would be nice to see when it gets released instead of general "bug fixes were done" 

Link to comment
Share on other sites

On 1/13/2018 at 1:15 AM, MADMAN32395 said:

I've been submitting tickets for this one bug. Kept getting told I was crazy, eventually got around to replicating it on here and other sites was told it was fixed. But haven't seen it released yet. It would be nice to see when it gets released instead of general "bug fixes were done" 

Exactly my point.. It would be nice that current software owners and up to date with "support fees" can access the bug list so we can see what is fixed and what is on the list to be fixed. 

Link to comment
Share on other sites

Why not start a topic Bugs and issues after 4.2.7 update and run with it in the open forum plus submit support tickets?

Seems like other members would keep it going and the site admin really shouldn't have a problem if they could hit a single thread for a running list of issues,

If a person like myself listed a bug and someone wants to offer help all they'd have to do is start a thread saying fix is located here and point you to it so you could keep the bug list clean from all the you can try this and that chatter

 

To me thats how a forum is supposed to run anyway...lol

I have a section for site related issues or questions...on my board

Link to comment
Share on other sites

33 minutes ago, Mark White said:

Why not start a topic Bugs and issues after 4.2.7 update and run with it in the open forum plus submit support tickets?

That's essentially the bug tracker re-incarnated. Gotta say, I don't miss that at all. Messy when you look back to it and created issues, Just my cents there. I hated submitting bug reports to tracker and so much getting listed that weren't bugs and so much getting over-looked. Still not a fan of submitting support tickets but it's a world better than what it used to be imo. Also, this way too everyone gets an answer. Wasn't that way either in tracker. Much more client orientated now imo.

Link to comment
Share on other sites

  • Management

Generally speaking, most bugs are in fact rectified in the next release and if not, within two releases. There are rarer exceptions, so please don't "you said it would be fixed within two releases!" me at a later date. If an issue is incredibly minor (misspellings, white space, etc.) it may be logged and made part of a larger batch of similar issues and if the fix becomes an engineering task that touches multiple areas, we will shelf it until a more appropriate time (and we try to let you know we have no ETA in those cases.)

If you're a third party developer encountering issues that necessitate "workarounds" - I'd encourage you to peruse the dev gateway forum when possible.

I do actually agree we can do a bit better job with release notes and we will make more effort to highlight big issues like "fixes embed issues in Firefox." We, like most providing commercial software, don't have provisions for providing detailed "changelogs." Our development notes and internal changelogs reference and pull ticket / incident numbers and bug IDs that have no relevance and would be of no help to the general public. Transcribing these for public consumption would (and for the short period we tried it, did) provide little benefit to the vast majority of clients who: have a problem with their community -> report an issue -> move on; thus the effort is not justified.

This is privately developed, commercial software, not an open source product like those referenced above, so there is a difference. It's rare to find detailed changelogs and details of every little thing a commercial entity does. Clients previously complained the bug system was a "black hole", bugs would sit, there was no communication, etc. We now ensure all issues properly flow through the client system using our own processes. It's difficult to argue that the proof isn't in the pudding on this one. The product is more stable, issues are very rapidly addressed and client satisfaction is significantly higher.

I think a select few get so entwined in bug trackers and changelogs not because of issues that impact them directly, but out of curiosity in what the company is doing behind the scenes and a deep-seated desire for full transparency. Those are not unfounded wants and I get it, believe me - but again, it's infinitely easier to field the occasional redundancy in support, than to stop developers to chronicle their every move in full terms fit for public consumption/comprehension. If an issue impacts your community to the level that you feel compelled to check a list or tracker after each release, chances are it's already been fixed and if not, feel free to let us know "guys, I know things can take time, but seriously, this is a high impact issue for us."

Quote

So what issues were identified in 4.2.6? 

If you have to ask, why would you care? (rhetorical question of course!) Seriously though, if you're having an issue with your community, we don't want you to ponder whether or not you should contact us. If you run the support tool and the issue is still present: please, contact us. We don't mind and that's genuinely what we're here for. Let us worry about any perceived redundancies and let us shoulder the burden. I do not follow bug trackers and changelogs for products I use - if I have an issue, I consider it support. If I don't have an issue, I don't go looking for one and don't particularly care if others are. I don't care how a company fixes it and don't care to see their progress as long as it gets fixed. I believe in providing our clients that same luxury.

This general topic has been dead-horsed many times over and ends in the same place. Please know, we love to hear what we can do better. In this case, we feel our development processes work best for us and the vast majority of clients. We will make a concerted effort to provide more big highlights in release notes, however, expanded changelogs, bug trackers, etc. are not on the roadmap.

As always, please feel free to reach out with any further comments/concerns. Thanks! :)

 

 

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...