I've setup our release definition in VSTS and when I go into a release there is a work items tab. When I first go into it it lists the work items that are in that release, but there is to get the work items associated with this release since a previous release. However, which ever release I choose I always get No release found with name '<Release Name>'.
Am I missing something? I've retained the releases indefinitely and they do exist. Is this a bug in VSTS?
Update - Following #marina's answer here is a screen shot of my Work Items tab:
As you can see I've got 1 bug work item in the list. This is the work item that was fixed in Release 212. This is what is displayed before I click Compare. On clicking Compare I get the error message "No release found with name 'Release 211 for build xxx Lite-CI-Nightly-refs_heads_develop_2017.11.7.2 develop'.". There is definitely a release 211 and it did have a work item associated with it. I'm getting the same error with any of the releases. Is there something I've missed with the release definition?
The compare work items in release can work correctly.
Please check if your current release has work item related.
In the release summary Tab, check if the release has linked with work item(s).
If the current release is not related with work item, when you compare with pervious release (work items associated with this release since previous release), it will show No associated work items found.
When you select an old release to compare, it actually show the work items from the old release (not contain) to current release.
Assume your current release is Release-4, and the linked work items with different releases as below:
Release Related work items
___________________________________
Release-4 none
Release-3 workitem3, workitem4
Release-2 workitem2
Release-1 none
For the current Release-4, it default show item associated with this release since Release-3 (current release and not include Release-3), so it will show No associated work items found.
And if you select item associated with this release since Release-2, it will show the work item linked in Release-3 and Release-4. So it will show workitem3 and workitem4 after you clicking compare button.
I find that in VSTS, the work items tab of the release menu allows to compare the current release with any previous release and get a list of work items added since then. This works well as long as work items are linked to commits during development (good practice). So all good.
The problem is with the 'send email' command, when using this the compare is to the last release even if it was never deployed. there is no way i can find to select a specific release to compare with.
Related
Since around 2 weeks ago, my console filter starts to filter out even matching text. Tried restarting, is currently on the latest chrome version, also tried to restore settings, nothing. Searched on the web too didn't really find anything similar... I am banging my head against the wall right now if anyone has a lead, please... (Apparently one of my coworkers also starts to have this issue recently... )
Edit1: So played with a couple versions of chrome more. I am current on 95.0.4638.69. Tried beta version 96.x, same issue. Tried chromium 94.x, it works all fine! Haven't got a chance to try chrome 94.x as I dont' want to uninstall my chrome yet. But yeah I am leaning towards that the 95.x updates may break it, though I haven't seen any official info regarding it.
Same issue on Chrome 95.0.4638.69 (latest as of 9 Nov 2021)
Workaround I'm using at present is to use Regular Expression format in place of standard filter string e.g. test -> /test/, then it works just the same
To filter by multiple strings separate with a pipe (OR) character /test|another/, and add an empty string pipe at the end to quickly clear filtering without deleting the filter /test|another|/
I have loaded DiffTool extension to compare two versions of a model. I just removed some elements from version 1 and upload it as a 2nd version. Here are the Model Browsers for those versions -
Now, when I compare these two versions I am getting many differences between the model versions which is much higher than what I expected. The comparison panel shows many items as Added, Removed and Modified. I have seen that though exact same item is present in both models(after the removed item in the model tree), DiffTool showing it as Added and Modified in version 2. Like this -
From a user point of view, I don't want to see this as an Added or Modified item. From the documentation, I am not clear how DiffTool compares items. Can you please help me to understand the way DiffTool compares models? And If I want to customize the comparison logic, is there any way for this? TIA
I'm trying to get more useful test results for our Hudson build, and I'd like to be able to sort all builds by last run date.
Unfortunately, It seems I can only sort by either last success or last failure.
Is there a way to add this functionality through the base app or via plugin?
Note that I already installed the extra columns plugin, but it doesn't seem to have this functionality.
Thanks
You can view execution history on per-node bases, and that is reverse chronological order.
For the master, goto:
http://<serverurl>/computer/(master)/builds
You can also get there by click on your master node in executor's list and clicking Build History
There is also an RSS feed with the same information:
http://<serverurl>/computer/(master)/rssAll
I'm trying to configure the FlaggedRevs extension to a Wiki based on MediaWiki (currently V1.19.1). I've read the documentation closely several times, but I can't quite achieve what I want.
My objective is to display the stable version of pages to users. Any edits must be reviewed against a single scale with four flags. Only once a page is reviewed to the top flag of the scale should the current version become the stable version.
What I've done so far: I've configured my own scale called content and its component flags; and I've configured users, editors and reviewers. The key scale configuration code is:
$wgFlaggedRevsTags = array(
'content' => array( 'levels' => 3, 'quality' => 2, 'pristine' => 3 ),
);
My results: When I edit a page those edits are viewed as pending. Users see the stable version of the page. All good so far. However, once I review the page and upgrade the scale from the lowest flag (0) to the next flag (1), the current version becomes the stable version. This is not what I want; upgrading to stable should require the top flag (3), not any flag but the least (0).
How do I configure FlaggedRevs such the stable version of a page corresponds to the pristine marker?
Edited to add: my experience and jpatokal's answer seem to differ. Does 'levels' => 3 give me flags(0,1,2) or (0,1,2,3). I get the latter, but is the extension adding a 0=Unreviewed flag for me or am I specifying it? How do the quality and pristine settings work too?
I was able to reach one of the extension authors via their Mediawiki talk page. Turns out the extension documentation is a little out of date. Here's the latest:
The flags determine whether a revision is checked/quality/pristine. These tiers can be queried at UnreviewedPages and PendingChanges (the special pages) to keep the quality/pristine versions up to date. By they are updated "asynchronously". That is newer "checked" versions "go live" before it gets marked as "quality" or better. This reduces the average time for people's edits to get through and simplifies the UI.
So my observation matches the currently intended operation. The visible (stable) version depends on the checked marker, The quality and pristine markers are kind of independent to this (but still have value in improving quality).
So the answer to my question, is perhaps there is no answer. That is, what I was after cannot be achieved directly as it's not the intention of the extension.
What is the best method to determine the version number I should use for a software or component? Is there a general rule to set version numbers?
I'm pretty sure it is a basic question but I didn't find anything useful after searching a while.
Microsoft have a convention of:
[major].[minor].[revision].[build]
Or follow Jeff's versioning system.
I've been doing this as an interim until I find a better solution. I don't build many large applications, mostly reports and smaller macros, but it's still important for me to keep track of changes and versions.
[Current year].[Current month].[Current day]
FileName 9.7.17.rpt for example.
It works for me and my boss, and it gives a value which you can compare to today's date to see how old the file is. I also keep a changelog.txt file in the same folder as the most current version and it keeps track of all the changes from the previous versions. I also keep track of all versions in a version control page on each projects tab in OneNote.
Thanks for the answer. I'll also throw in how I store the projects for giggles.
Every project gets its own folder. Inside that folder I'll have 4 main items that help me keep track of what's going on in the project.
An old versions folder
A folder for any reference material I might need for the project
The actual project file
And the changelog
That tree will look something like this.
Project X
Old versions
X Report 9.4.12.rpt
X Report 9.5.3.rpt
X Report 9.7.20.rpt
Reference
SQL calls.txt
Client list.txt
Procedures.doc
X Report 9.7.29.rpt
X Report changelog.txt
This way of keeping track of my work really cuts down on the amount of time that I need to spend documenting anything and organizes it in a standard way so if my boss needs to grab something I've worked on, even he knows exactly what everything means and where it is.
For storing multiple projects in my network folder I have these folders.
Inbox
Projects
#Archived Projects
Current Project 1
Current Project 2
Current Project 3
Reference
Inbox is where I toss random things to process later, or a folder where my boss can throw something I'm going to need for a later project. The Projects folder contains all the projects I'm currently working on, and then when I'm done or they no longer become a current priority, they get tossed in #Archived Projects. Reference is a folder for general job reference material, like policies and procedures, phone lists, org charts, fire escape plans. I may never use them, but it's comforting to have a place to put that kind of stuff as opposed to digging through old email.
This is a very common question. Are you sure you searched around? Wikipedia has a good article on software versioning.
Or, you can follow Ubuntu's convention of using year and month.
For example, release on April 2009 would be:
v9.04
Do it like Donald Knuth does with TeX---its version converges to π with each release and will in fact become π when he dies.
Since version 3, TeX has used an
idiosyncratic version numbering
system, where updates have been
indicated by adding an extra digit at
the end of the decimal, so that the
version number asymptotically
approaches π. This is a reflection of
the fact that TeX is now very stable,
and only minor updates are
anticipated. The current version of
TeX is 3.1415926; it was last updated
in March 2008.
from Wikipedia
A common scheme seems to be to use [major].[minor].[revision]. Where the major version number increments on large/major feature changes or rewrites (or stays 0 as long as you didn't reach a stable version, although many open source projects never get past 0 here), minor version number increases on minor changes, such as a collection of bugfixes, an added small feature and the like. revision increments with each build and reflects the smallest granularity of tracking your exact version. Things like small fixes, etc. get rolled into this, usually.
Usually the first number are major changes/major releases, the second number are used when minor features and bug fixes are added, and the third number is used for minor bug fixes and revision numbers.
Ex. 1.0.0
Depends on a lot of things.
If you are doing .Net work, you can have the system keep track of version numbers for your .dlls and .exe files automatically.
We frequently use the subversion revision as part of our version number. We use a system like:
major.minor.svn-version
We increment the major/minor manually based on internal decisions, and have the svn-version propagate to distinguish builds.
The most important thing is that version numbers make sense to your users.