Silent update suggestion

[Alan Baxter]

I've noticed a couple of times in the past week or so that Giorgio says he modified the installation (xpi) file without bumping the version number (silent update). http://forums.informaction.com/viewtopi ... 762#p18762
I suggest bumping the version number when there's any modification, but especially when there are any changes in the code. Here's why:
- It can make regression testing problematic if I can't differentiate them by version number.
- When I'm trying to help another user, I would like to know if he or she is using the exact same version I am.
- If the version number isn't bumped, then I can't tell whether I'm using the most current version.
- I'm not notified by the RSS feed when an xpi file is updated without a change in version number.

[GµårÐïåñ]

Sounds like a reasonable request if the change are accompanied by any code difference; however, in cases where the correction is a matter of cleanup or housekeeping, then it shouldn't pose a great problem to keep the version numbering the same. Often changes need to be at a certain level to constitute a version bumping necessity and the bumps are progressively larger depending on the extent of the changes, but in many cases where the number is kept the same, they tend to be so "insignificant" that a version bump could actually be more misleading than keeping it the same.

[dhouwn]

A common user should use the stable version unless he needs a fix right away.

An idea of mine: Giorgio makes the repository public together with the 'build'/package scripts (sans the private key of course) so that nigthly testers need to create their builds themselves and for reporting a problem they use the revision number.

[Alan Baxter]

Sounds like a reasonable request if the change are accompanied by any code difference; however, in cases where the correction is a matter of cleanup or housekeeping, then it shouldn't pose a great problem to keep the version numbering the same.

The two changes that Giorgio announced contained changes in functionality -- obviously code changes. In my experience, it's safer if non-functional housekeeping changes are included in a subsequent version rather than silently updating a version which has already been released.

A common user should use the stable version unless he needs a fix right away.

Actually, the development builds are as stable as the builds pushed from AMO and are recommended for all users that want to bother getting them. From http://forums.informaction.com/viewtopi ... 9867#p9867

Is the dev build stable enough to get, or should I wait until Firefox "formally recognizes" the update?

Due to my development model, latest dev build is always the best version available (the one I use for my daily browsing).
Unless an outstanding bug or security enhancement is mandatory, though, I try to put at least one week between "stable" releases, since some users find automatic updates rather annoying.

General Troubleshooting Instructions

update NoScript to the most recent development build

[GµårÐïåñ]

The two changes that Giorgio announced contained changes in functionality -- obviously code changes. In my experience, it's safer if non-functional housekeeping changes are included in a subsequent version rather than silently updating a version which has already been released.

I wasn't denying that or arguing that point, I was simply stating it as a matter of practice. Now if the code is RELEASED, then yes, changes would be best kept for next version or should come with a small revision bump; however, if they are still DEV build release, then changing it is not an issue and shouldn't be an issue since by the very nature of it being a pending DEV build, there is room for wiggle.

I confess that I don't know exactly which build you were referring to and looking at the link you provided, I am still not 100% sure; but the content of my statement is still valid in practice and gleaming from what another posted, I am assuming it was still officially a dev build. Anyway, I was simply adding some perspective, the person who can truly answer you with regards to the reason is Giorgio, and I did agree that it was a reasonable request, so there really should be no issue there.

Actually, the development builds are as stable as the builds pushed from AMO and are recommended for all users that want to bother getting them. From http://forums.informaction.com/viewtopi ... 9867#p9867

That's generally true and holds valid but up until it is ACTUALLY released, it is indeed a pending, working build, that although de facto ready to go, subject to modification before officially released. See what dhouwn meant? and what Giorgio meant? and what I meant? Again, it IS de facto the best and most recent build (because it has changes since last build) and de facto ready for release (because all perceived or decided changes are made), it is still a developmental build which means it is a work in progress (containing the latest goodies) but still, a work in progress or it would have been officially released. When he has no more changes to make or is happy that its running as well as can be hoped for, then he releases it, then its done and changes will garner a new version bump.

Anyway, its all semantics and open to interpretation but while in DEV mode, its open to modification still until it becomes RELEASE and then it will trigger a version bump. That's as general and wide of a definition that I can think to satisfy all expectations. In the end, just my two cents.

[al_9x]

Ideally, every distinct build should have a unique identifier so it can be referred to without ambiguity.

[GµårÐïåñ]

Yes, ideally you would, but something that is a work in progress, is really not its own entity yet until its actually released. I am sure that despite the outward appearances, it does indeed increment revisions but probably not showing on the publicly visible version number. When I developed for public consumption, I always made a point of showing the build/revision numbers as well, because many time the tweaks would be done without a version bump (because it didn't warrant it) but the revision tells the user, oh yeah something changed, may have been correcting "aBout" to "About" but still something revised, hence the micro bump, but nothing that would warrant a x.1 or 1.x bump. See what I mean?

[Giorgio Maone]

OK, I've just been lazy. I agree having unique build ID for each change, albeit minimal, is the ideal course.
Locking