Is it possible to specify more product versions in single Bugzilla bug?
That'd help the need to clone the same bug several times.
The best thing is probably to use Tracking Flags for the different versions to be track of affectance, fix state, …
Related
I've been trying to work with Codename One for years, but I still find errors that prevent me from releasing my apps.
Locally I can fix errors by I overshadowing erroneous classes. This works but for some reason it doesn't work when I send my apps to the build server.
If I could overshadow faulty classes would be good in many ways:
I'd better get on with my work
I could check how my corrections work on the different platforms
I could contribute to the further development of Codename One
I suffer much from not being able to publish my apps because I see no way how I can fix basic problems.
I love iPhones and do not like the Mac. Therefore I do not own a Mac and prefer to work with Linux and use the Codename One build server.
What are the reasons for not supporting overloading classes like com.codename1.ui.Component? Can You see that it would be beneficial?
This isn't the first time people asked for that but we won't deliver it. Doing this creates huge problems:
Developers don't file issues or submit fixes instead they make local fixes
Developers break things due to complex behaviors then try to get support and blame us for the issues
We have a process of submitting patches to Codename One, patches are always accepted quickly when they are valid. If something needs fixing that's what you need to do. If you need a hack then submit a patch that defines the extension point that you need. That's why we are open source...
In the past this might have been painful as you would need to wait until we updated the servers, but since changes go in every week in recent revisions this is no longer an issue. Don't think of it as "contributing", think of it as free code reviews where the entire community pulls together to improve your work...
I'm trying to make a merge operation with Subversive in Eclipse.
I've been able to manage all the conflicts on the files structure, but it remains a conflict on the svn:mergeinfo property.
I've tried everything, but I'm not able to solve this conflict:
The plugin has a Mark as merged option, but it doesn't happen anything choosing that option.
I have also tried to remove the property, or to modify its own value, but nothing happens in any case, and the conflict is still present.
If I try an Override and commit, the status of the Folder of the project is Conflicting, also visible in the SVN Info on the properties of the project.
It seems that Subversive can't manage a conflict on this property: is that possible?
How can I solve this conflict?
Thanks in advance!
Even though I haven't found yet a solution directly with Subversive, I hacked the issue using a tool like SmartSVN.
With that tool I had been able to mark the conflict as solved, so I can say that it's a bug (or maybe a missing feature) of the current version of Subversive.
Is it possible to customize Bugzilla bug numbers and add a letter designator, to immediately know it came from Bugzilla?
My company is evaluating Bugzilla and has now added many new bugs. We also use 2 other bug databases. This wasn't my decision and I believe they were trying to incorporate better reporting, etc.
I read an answer here about "seeding" Bugzilla bug numbers, by setting the "AUTO_INCREMENT" field in the "bugs" table to a different value. I wish I would've thought about this sooner and found this board. Setting that value to start at 9000 or some extraordinary value would have ensured that we knew exactly which bugs came from Bugzilla.
However, would it be possible to change the field in the "bugs" table to accept letters, as well? Of course that would probably just mess up the whole auto incrementing of the numbers.
Any help or advice is greatly appreciated. Thank you.
It is not a trivial matter to do what you're asking.
However, you can still change the "seed" value for the Bugzilla database if you want. Export the existing bugs to xml, then create a new Bugzilla database. Change the seed. Then re-import the bugs. They will now all use the large bug number.
This is a general question but I'll illustrate it with Eclipse. I recently reinstalled Eclipse and find that the distribs are called
eclipse-java-galileo-SR1-win32
and
eclipse-java-ganymede-SR2-win32
(I also have a "europa" from the past - what happens when we run out of Jupiter's moons?)
I find this very confusing as there is no indication of which version is the latest and in fact I muddled them.
This is not restricted to Eclipse, and several version of software come out with version names (e.g. the Mozilla family). Personally I would much prefer the normal decimal version numbering. What other examples are there of name confusion and is there any justification for it?
update some early replies suggest some people prefer names to numbers and vice versa. Could we not have both, therefore?
update A majority view (but not consensus) seems to be emerging that names are useful for developers before release but that n umbers are better after release
Names have long been used as code names during development, so that developers could refer to a name rather than a number all the time ("version 5.67 branch 2" doesn't roll off the tongue as easily as "bob").
But from the point of view of the end user, they suck. They only convey information to someone if they know the list of version names used. A user doesn't care that they are about to download "rancid cheesecake" to replace "fetid sardines". What they want to know is that they have 2.1 installed, but there is now a 3.0 available.
Year numbers sit half way between the two. They're numbers that are often completely made up, making them simply names - We've been using 3DSMax 2010 for months now. In another month the name might even coincide with the calendar! To confuse us even more, we have Visual Studio 2005 which is version 8, and Visual Studio 2008 which is version 9.
Argh!
I think version names are pretty much only useful when it comes to marketing software to new customers / non technical people. It gives the marketing guys something to shout about.
Anyone technical will always want to deal with version numbers because (if used properly) they will tell you which order the releases were done in. You should also be able to get an indication of the magnitude of the release by looking at which part of the version number has changed.
I find it nice to have names and numbers for every release. For example, Apple lists Mac OS X as "Mac OS X 10.6 Snow Leopard" in their store. This prevents confusion over order while giving a nice natural name to it. Also code names are nice for talking about releases among those who know the software intimately.
Names are for usability. People are just more comfortable with referring to things using words rather than numbers, especially in spoken conversations.
I agree that numbers also come in handy to convey information about a release e.g. the date of the release or its age compared to other releases. In my opinion, both have their place.
I like the way Ubuntu names their releases with both a catchy name and a number e.g. Jaunty Jackalope 9.04 (which was released in April 2009).
As jensgram commented, Ubuntu's naming scheme also has the advantage of encoding order by assigning their human-readable names in alphabetical order. It's easy to tell that Karmic Koala is the release after Jaunty Jackalope.
Ubuntu does it, OSX does it, it drives me insane. Microsft at least is moving to version numbers again, woohoo!!
It's easier to talk about the release verbally using code names. When developing on several branches, it's easy to get confused when a lot of numbers start getting bandied about in conversation.
This is probably a Good Thing for developers while the code is being worked on, but quickly becomes annoying after the release happens, and the order of the releases isn't obvious. IMO codenames are all well and good, but after a release, use the number!
Apple OS X versions.
As a person with only a little Mac experience but sometimes supporting the thing. I find this confusing.
On the other hand when you actually know what the latest is. It is easy to ask someone if they have the latest. Since the word for some people is easier to remember than a number.
I have been struggling with versioning software for a while now.
I'm not talking about a naming convention, I'm talking about how to actually apply a version in a build system all the way through to a release.
I generally use major.minor.maintenance-[release type]
i.e. 1.0.2-rc1
The problem is managing the version number. I've tried many ways (sticking it in a build file, a properties file, a database, etc,etc) but I haven't found anything that really works well.
The closest thing I came up with is using Jira which I documented here:
http://blog.sysbliss.com/uncategorized/release-management-with-atlassian-bamboo-and-jira.html
I'm wondering if anyone has any good ideas about this.
Also, wondering how people handle releasing a version.... i.e. If I release/deploy version 1.0.0-rc1 do bugs found in this release then get logged into 1.0.0 (the next/production release).
Microsoft uses <major>.<minor>.<patch>-<build number> (or a variation).
I like using <major>.<minor>.<buildnumber>
Where I'm working we use the Maven system: artifact[-major-minor-revision][-SNAPSHOT] which allows us to develop "in progress" versions that change at a moments notice (SNAPSHOT) and those which have been formally released. Some examples are:
email-services-1.0.0-SNAPSHOT.jar
email-web-2.3.11.war
crm-2.5.0.ear
If it has SNAPSHOT in it then it hasn't passed the full suite of tests or is just a developer experiment. If it doesn't have SNAPSHOT then it is a release candidate. We maintain a repository of release candidates and the most recent is sent for deployment once the testers are happy with it.
All of this can be managed with a few simple entries in a build file under Maven. See Maven2 tutorial
This is probably a dead post now, but I'll add my two cents anyways. I'm of the opinion that build numbers should mean something to everyone who sees it. So I personally think that this is a good way to name versions:
major.minor.patch.revision - e.g. 1.1.4.2342
Major/minor numbers are pretty self-explanatory. But from the perspective of the 3rd number, it still needs to mean something to the customer. I've released this new version to you, Mr. Customer, but it wasn't worth a new minor number since we just fixed some bugs. So we've incremented the patch number.
The 4th number usually means absolutely NOTHING to the customer, so you might as well make it useful to you and anyone else in your company that sees it. So for us, that number is the SVN revision number. It tells us exactly which revision was responsible for that version so that we can pull it out any any time to recreate it. Branching code obviously achieves this too, but not to 100% certainty.
Also, another advantage with an all-numeric version number is that it easily integrates into nearly every continuous build system.
Anyways, that's my two cents.
+1 on the Jira/Bamboo solution. The only additional information about the build I would include (for my purposes) is the Subversion Release, although the Tagging operation is 80% of what I want.
Manually maintaining the release/version information is a royal pain. Letting JIRA drive it is a great idea.
On the final question, about where bugs/defects get logged and releasing a version:
Defect/Issue is logged against the release where it appears. A defect in 1.0.0-rc1 gets logged against 1.0.0-rc1
JIRA has (or maybe we added) a 'Fix-For' field that would have the planned release, in this case 1.0.0
If the defect/issue is severe enough, it may be necessary to add another 'rc' release.
The release is made when there are no outstanding critical defects/issues and the customer (or management) agrees that any remaining issues can be deferred
The beauty of managing this through JIRA is that adding releases, generating change-logs, etc. is automated fairly well.
We also use <major>.<minor>.<buildnumber> and we manage this with CruiseControl/(.Net) on our build server. And use Wix and CruiseControl Config to manage the Major minor numbers - still increment those by hand - but the build number happens automatically when on the build server. You could set up a rule an increment the major/minor automatically too I believe - we just have like to do that manually so that it takes concious thinking by a dev when it is time to name a particular release level.
Major.Minor.BuildDateNumber.DailyBuildNumber
Major and Minor are set by us, manually incrementing them as we see fit.
BuildDateNumber is the number of months since the project start multiplied by 100, plus the day number of the current month.
DailyBuildNumber is incremented for every build after midnight each day, starting at zero.
E.g. 4th build of release 5.2 on 10 July, where the project started 1 Jan that year, would have version number
5.2.710.3
This is all calculated for us by the Version task in Nant.
This keeps the version numbers unique and also allows us to quickly calculate when an installation was built.