3.4.x Beta

[conquerist]

My main issue is that the Search bar has disappeared!

 

The search bar will disappear if the toolbar was hidden (F4) the last time uTorrent was closed. Apparently this has been happening for a while now. Maybe that applies to your case.

[opHaido]

 

The search bar will disappear if the toolbar was hidden (F4) the last time uTorrent was closed. Apparently this has been happening for a while now. Maybe that applies to your case.

 

 

Pretty sure the toolbar was displayed when I upgraded. And to confirm, the search bar reappears upon downgrading.

 

Thanks for the suggestion though, this is useful information.

[cfw]

And? Should everyone guess/know how it operates? Not so difficult to mention the need for using of the player tab, which is missing...

Heh, true. On other hand, it could just be that people think they fall into the group that's not part of the trial, and therefore don't know there's a bug.

[rafi]

Yes, the principle of uncertainty rules! (aka Russian roulette... ). And the 'lucky' ones are being left ignorant...

[ChristinaBT]

rafi and conquerist, thanks very much for the info. i was able to reproduce the problems and file a bug.  

[zdnko]

Suddenly slow and with black and white graphic

http://prntscr.com/6qugr6

Edit: Ok after restart

[conquerist]

rafi and conquerist, thanks very much for the info. i was able to reproduce the problems and file a bug.  

Thank you. Can you please keep us updated on further progress, e.g. when this bug is fixed?

[Seyss]

dafuq the tab bar is gone!!!

edit: even with the latest version is gone

[Ryrynz]

dafuq the tab bar is gone!!!

 

Yeah noticed that with an earlier beta build as well, I updated to 39910 and the tab bar was back.

Bittorrent team, why can't you release a version and then increment the version number then run builds until it's stable and rinse and repeat?

I don't get it, 3.4.2 in dev for a year adding features and fixes then boom suddenly it becomes 3.4.3 for no reason, then you continue to run the builds up.. doing the same thing.

Which means 3.4.3 "final" (The final build) which is likely one build off from becoming 3.4.4 is going to be fairly different (changes wise) to the 3.4.3 that was first released.

It basically means the version number means next to nothing.
 

Release --> Increment version number -->  use beta build numbers --> Release

Rather than

Release --> use beta build numbers --> Release

You're using beta build numbers in place of version numbers and it doesn't make much sense.

Why do you not do it the same way every other software company in the world does it? You don't need a build number when you have a release version number.

How are trackers supposed to know what they're approving when you make version number style changes with build numbers?

Why don't you consider 3.4.3 as released now and update the beta builds to 3.4.4, there's nothing wrong with releasing a .1 update within a few weeks of having released a previous version.

Also the fact that you guys straight up miss glaringly obvious bugs like the tabs bar disappearing is of obvious concern even if they're betas.. you guys still aren't even giving these builds a glance over before you update the links.. So my question is, what makes you update the builds here in the first place?

[talkingprawn]

Hi all, we just posted an updated beta (39991).  I believe it fixes the funky status bar alignment and the redraw flickering/slowness/stalling issue.  We're still working on the other issues raised here, and will have an update on that soon.

 

Btw ryrynz, the tabs bar disappearing is a bug that only seems to happen when people manually place the binary in AppData and run it over a previous install.  It's an edge case and yes it's not something we tested -- nobody thinks of everything the first time.  There's a reason this is a Beta track, and we very much appreciate and value your willingness to help us out.  If you're frustrated with the imperfections of the beta cycle, we have a good stable main release you can get on and not experience these fluctuations.  We're very happy to have you all here helping us work out the kinks in the latest versions though.

[mike20021969]

Hi all, we just posted an updated beta (39991).  I believe it fixes the funky status bar alignment

 

Thanks for the update

 

-- 2015-04-08: Version 3.4.3 Beta (build 39991)

- All fixes from the latest stable (39744)

- Update to beta 39910

- Crash fixes

- Display issues fixed

[Ryrynz]

Btw ryrynz, the tabs bar disappearing is a bug that only seems to happen when people manually place the binary in AppData and run it over a previous install.  It's an edge case and yes it's not something we tested -- nobody thinks of everything the first time.  There's a reason this is a Beta track, and we very much appreciate and value your willingness to help us out.  If you're frustrated with the imperfections of the beta cycle, we have a good stable main release you can get on and not experience these fluctuations.  We're very happy to have you all here helping us work out the kinks in the latest versions though.

Finally, a dialogue!

I haven't manually placed the exe in the appdata, uTorrent default installs to the roaming directory under appdata., that's not an edge case.

Okay so let me address the beta cycle. I have no issues with beta imperfections (although stable is generally almost as buggy) This isn't the issue.

The issue is how you guys label them, there is no clear, concise defined version number, you're using build numbers (which should only be used in testing not in release)

The way nearly all software development goes is that there is a goal for a particular version number.

Main release.minor release.bug fix release  then build numbers designating branches in testing builds, this is generally how most versioning systems work.

 

As it currently stands you've already released 3.4.3, but yet it's still in beta and this makes no sense.

If it's a beta build it's the subsequent version, in this case beta builds are in fact 3.4.4 since 3.4.3 has been released.

If you plan on making larger changes then create a new branch of 3.5 and have a beta branch and an alpha branch (just like there used to be)

Smaller changes go into 3.4.x and it's released over the course of a number of weeks or a couple of months depending on the changes or goal in mind.

3.4.2 never should have went on for as long as it did, everyone saw how the constant code changes made it a complete mess. Compare the code changes between 

the earliest build of 3.4.2 to the last one.. the amount of fixes was high and likely the result of constant changing of code.

Please, I urge you to avoid continuing in this fashion.. you would gather more respect if you managed version numbers as I outlined above.

Then at least we know what we're dealing with when we see a certain version number.

 

[rafi]

Btw ryrynz, the tabs bar disappearing is a bug that only seems to happen when people manually place the binary in AppData and run it over a previous install.

Just curious, how do your QA people update from previous betas if not by replacing the binary? Since you've disabled "update to betas" in betas, and manual help->update does not work for years now...  what else can you do? And especially if the files are not in appdata, but 'standalone' somewhere else?

[cfw]

Just curious, how do your QA people update from previous betas if not by replacing the binary? Since you've disabled "update to betas" in betas and manual help->update does not work for years now...  what else can you do? Especially if the file is not in appdata, but somewhere else?

+1.

 

Since the betas are usually just the exe, that's the logical approach to using it. I've done it this way for years and have had very few issues.

[cfw]

Okay, I just tried build 39991 and I still have one pesky issue dealing with the torrent-list.

My test-bed has close to 29k torrents in the list, it's intentional to see just how many torrents it can use.

Earlier builds crashed at around 25k, so there's improvement, however the issue I face now is if I try to interact with the FULL list, ie select the Torrents filter, the application will end in some loop where it will continue to run, but be unable to update/complete the interaction. Eventually I will just have to kill it.

 

I realize I'm pushing the boundaries of what a 32bit app can handle, but I am wondering if the devs have some input on this, perhaps consider adding a feature which will prevent loading of the torrent-list if it becomes too big. One possible idea off the top of my head would be to auto-split the list into several lists so this cannot happen.

 

Comments people?

[rafi]

Finally, a dialogue!

I haven't manually placed the exe in the appdata, uTorrent default installs to the roaming directory under appdata., that's not an edge case.

Okay so let me address the beta cycle. I have no issues with beta imperfections (although stable is generally almost as buggy) This isn't the issue.

The issue is how you guys label them, there is no clear, concise defined version number, you're using build numbers (which should only be used in testing not in release)

The way nearly all software development goes is that there is a goal for a particular version number.

Main release.minor release.bug fix release  then build numbers designating branches in testing builds, this is generally how most versioning systems work.

 

As it currently stands you've already released 3.4.3, but yet it's still in beta and this makes no sense.

If it's a beta build it's the subsequent version, in this case beta builds are in fact 3.4.4 since 3.4.3 has been released.

If you plan on making larger changes then create a new branch of 3.5 and have a beta branch and an alpha branch (just like there used to be)

Smaller changes go into 3.4.x and it's released over the course of a number of weeks or a couple of months depending on the changes or goal in mind.

3.4.2 never should have went on for as long as it did, everyone saw how the constant code changes made it a complete mess. Compare the code changes between 

the earliest build of 3.4.2 to the last one.. the amount of fixes was high and likely the result of constant changing of code.

Please, I urge you to avoid continuing in this fashion.. you would gather more respect if you managed version numbers as I outlined above.

Then at least we know what we're dealing with when we see a certain version number.

Regarding the above, I believe that this process has been designed  to achieve fast-tracked fixes, where every beta has a single fix (so it can be easy to pinpoint issues) , and the next "stable" will integrate a few, and be better tested. And I am not trying to justify this, just to see what the  the pros are...

As for 3.4.2 - the was only one real new "feature" in it (if we disregard all pro/ads/bundles) related "features" which is:

 

- This is the first good build with a huge behind-the-scenes change to how we update the Torrent UI elements from the network thread. The client should be much smoother to interact with when many torrents are loaded and active.

Only now, the related side-effects/bugs are starting to stabilize. I can easily list many more regressions that are still not fixed, and are in there (some you can see in my not-up-to-date list/sig). So there is nothing "wrong" with the time it take to change the *real* stable version # (except it taking too long...) , it was simply not ready...

[rafi]

Comments people?

With all due respect (and there is), there is this sane-test limit, which you have exceeded ... ;P

[talkingprawn]

Okay, I just tried build 39991 and I still have one pesky issue dealing with the torrent-list.

My test-bed has close to 29k torrents in the list, it's intentional to see just how many torrents it can use.

Earlier builds crashed at around 25k, so there's improvement, however the issue I face now is if I try to interact with the FULL list, ie select the Torrents filter, the application will end in some loop where it will continue to run, but be unable to update/complete the interaction. Eventually I will just have to kill it.

 

I realize I'm pushing the boundaries of what a 32bit app can handle, but I am wondering if the devs have some input on this, perhaps consider adding a feature which will prevent loading of the torrent-list if it becomes too big. One possible idea off the top of my head would be to auto-split the list into several lists so this cannot happen.

 

Comments people?

 

Well now *that* is some high octane testing, thank you CFW for pushing the limit.  

 

I believe the two-part response to that is:

 

1) with a limit that high it seems unlikely the team will prioritize adding a hard limit.  I do love that apparently we accidentally raised the limit by another 4k.  If the limit was a lot lower it would make sense to put UI in place to keep people from adding too many torrents and causing the product to stall, but even at 20k it seems like that's a very edge case and any use case involving that would be very advanced and the user should be prepared to work around some boundaries.

 

2) that said, please speak up if you do see a use case for this -- I don't want to make assumptions.  I'm reading what you said here as it being purely a test, and we love that.  But if there's a use case for this we definitely should know since our primary goal should be supporting how people use the product, not supporting how we assume people use the product.  And -- in your tests was it really 25-29k until the UI becomes appreciably unusable?  If you have any info about your experience at lower but still sizable numbers of torrents as you got to this higher number we'd love to hear those also.

[talkingprawn]

Finally, a dialogue!

I haven't manually placed the exe in the appdata, uTorrent default installs to the roaming directory under appdata., that's not an edge case.

Okay so let me address the beta cycle. I have no issues with beta imperfections (although stable is generally almost as buggy) This isn't the issue.

The issue is how you guys label them, there is no clear, concise defined version number, you're using build numbers (which should only be used in testing not in release)

The way nearly all software development goes is that there is a goal for a particular version number.

Main release.minor release.bug fix release  then build numbers designating branches in testing builds, this is generally how most versioning systems work.

 

As it currently stands you've already released 3.4.3, but yet it's still in beta and this makes no sense.

If it's a beta build it's the subsequent version, in this case beta builds are in fact 3.4.4 since 3.4.3 has been released.

If you plan on making larger changes then create a new branch of 3.5 and have a beta branch and an alpha branch (just like there used to be)

Smaller changes go into 3.4.x and it's released over the course of a number of weeks or a couple of months depending on the changes or goal in mind.

3.4.2 never should have went on for as long as it did, everyone saw how the constant code changes made it a complete mess. Compare the code changes between 

the earliest build of 3.4.2 to the last one.. the amount of fixes was high and likely the result of constant changing of code.

Please, I urge you to avoid continuing in this fashion.. you would gather more respect if you managed version numbers as I outlined above.

Then at least we know what we're dealing with when we see a certain version number.

 

 

I do admit there's some wisdom in what you're saying about the version numbers.  We have been discussing that internally and agree that there has been some amount of too-rapid, too-loose churn in our release process.  The fix for that may not come immediately but I do think we're on a path right now to making that a bit more predictable for you.  I appreciate the feedback here.

[talkingprawn]

Just curious, how do your QA people update from previous betas if not by replacing the binary? Since you've disabled "update to betas" in betas, and manual help->update does not work for years now...  what else can you do? And especially if the files are not in appdata, but 'standalone' somewhere else?

 

Ok... there's some news to me there.  We definitely want the beta update process to be usable and predictable.  Let me get this to some QA internally and wrap our heads around this, we'll fix.

[rafi]

We definitely want the beta update process to be usable and predictable

Exactly, we all do, and easily update-able too!

[mike20021969]

3.4.3.40019 now available:

 

-- 2015-04-09: Version 3.4.3 Beta (build 40019)
- All fixes from the latest stable (39744)
- Update to beta 39910
- Crash fix

[Ryrynz]

Only now, the related side-effects/bugs are starting to stabilize. I can easily list many more regressions that are still not fixed, and are in there (some you can see in my not-up-to-date list/sig). So there is nothing "wrong" with the time it take to change the *real* stable version # (except it taking too long...) , it was simply not ready...

Then by all means call 3.4.2 a day and move to 3.4.3 and then to 3.4.4 etc.. If I imagine I was controlling version numbers uTorrent would be above 3.4.5 right now.

.1 releases shouldn't take more than a few months (unless development has halted) If it does, then there's room for improvement.

Bug fixes are of higher priority and should be released as quickly as possible (with proper testing of course) And that's what x.x.1 releases are all about.

 

I do admit there's some wisdom in what you're saying about the version numbers.  We have been discussing that internally and agree that there has been some amount of too-rapid, too-loose churn in our release process.  The fix for that may not come immediately but I do think we're on a path right now to making that a bit more predictable for you.  I appreciate the feedback here.

 

Appreciate the reply. Cheers.

[schnurlos]

The new 3.4.3 beta build 40019 still has the issue with disappearing of the tab bar (as already at build 39891 here: http://forum.utorrent.com/topic/88339-34x-beta/?p=505436)

[thexfile]

For me, on 40019 when the tabs are missing I'm noticing the Playback tab keeps coming up unchecked to show. Once I check the playback tag (to show) all the tabs come back.