Had a question related to Semantic Version
We have two levels of customers - Levels 1 & 2. We have a current release (Say 1.0.2). We did a release for Level 1 with a minor number change (1.0.3) - but then decided that it will not go to Level 2. Now the next release should go to both Levels 1 & 2. But if we release it with 1.0.4 then it will look like a skip for Level 2 users. If we stick with 1.0.3, it will conflict with our Level 1 users.
So, for from a Level 2 users point of view, Would it be strictly consistent with Semantic Version if we skip a version number?
Any links could help. Thanks.
It's just fine to skip a version number.
Related
I have 2 fields "title" and "body" in my document. I want to give more weightage to title field. In latest Lucene 8.6* setboost is not available for field object. I want to know the best way to do this. I read PerFieldSimilarityWrapper can be used but I didn't get how to use it and in documentation warning is present "WARNING: This API is experimental and might change in incompatible ways in the next release." So is it safe to use in product which will be supported for long time.
I too wish I understood more about why Lucene sometimes marks portions of their API as "experimental". But one thing I can tell you, which should be fairly reassuring, is that there are large portions of the API marked this way and many haven't changed much in years and years.
So for example the class you are interested in PerFieldSimilarityWrapper was marked as experimental at least as far back as Lucene 4.8. See the tag on the 4.8 version in github.
So, I don't think I'd be too concerned. Especially because if the Lucene team ever decides to change the API they won't immediately remove it. They typically mark the old API as depreciated (but still callable) for at least on major version.
I'm currently using GitLab Enterprise in a team project. I now want to build out a board-based roadmap similar to Pivotal Tracker, Aha or Trello. (For this view, each month would be a "list" or Aha "milestone". We could then drag roadmap items from one month to another and the whole team can see where we are and our Issue priorities visually.)
I'm hoping we can only use GitLab for this and not need to integrate yet another tool.
In the "Boards" section of GitLab, I see I can make lists from GitLab Labels. This is OK, but I'd really like to make lists from GitLab Milestones. (Otherwise, I'd need to make another Milestone just to capture everything in the label.)
Am I missing something? Or is that really the best way to approach this with GitLab?
There is a roadmap feature for GitLab (premium/ultimate only)
It has evolved with GitLab 14.8 (February 2022)
Additional display options for roadmaps
In this release, we have introduced additional progress tracking capabilities to roadmaps. You can now view the percentage of completed epics based on issue count instead of issue weight. This functionality is useful for organizations that are using Kanban or other methodologies that don’t require their teams to set a weight on issues.
You can now also customize the level of milestones to include in your roadmap, allowing you to tailor your view to meet the needs of your audience.
See Documentation and Issue.
Milestones weren't designed with this use case in mind. Generally, once an issue is assigned to a Milestone, it doesn't change.
A common use case for milestones is to track Sprints or Iterations as milestones. The milestone's start and due dates would be the sprint start/end date respectively. During planning. issues would be tied to the appropriate milestone based on the sprint. If the work isn't finished by the due date (within the sprint period) the milestone stays the same.
Another use case is to use a milestone to track a scheduled release. In this case the start date can be empty, and the due date would be the release date. With this, if the release is missed the milestone still stays the same (ie, the issues are still attached the same) but it's completed after the due date.
Milestones do give some useful views about the attached issues, but not a board to move issues between them. Like you mentioned the only way to do that is with Labels, but they should work fine. You can customize the Labels you want to show up on a Board, and they order they're in. The only annoying (to me) thing about boards is that you can't get rid of the Open/Close lists, you can only collapse them. Looking at this issue (https://gitlab.com/gitlab-org/gitlab-foss/-/issues/37747) I doubt it will ever happen.
If you use gitlab.com, https://gitboard.co/ has the milestone or epic board which could help your case. The auto sprint could create and close the regular scheduled milestone/sprint or whatever you call it.
Yet another weird story from Domino Designer 9.0.1:
The application in question is set to support German and English; German is set to be both the source and the default langauge.
Over the course of the past few weeks we observed that there are some CustomControls and Xpages whose properties files are multiplying; within something like 12 hours we often see hundreds of multiplied files (currently we have 120 multiplications; earlier this week we had a case with > 1000 multiplied propertiey files!) In package explorer they turn up like this:
As you can see there is something like a docUnid added to the property's file name. Apart from a different time stamp they all are identical internally. In same cases both language versions are multiplied, in this particular case here only the German (= source) version shows that phenomenon.
Another strange fact: this particular custom control hasn't changed for quite a while, and it only contains a single control with a static text attribute, alongside a
Anyone having an idea what could be causing this, and what possible solutions I could try?
Tech facts and some more observations:
Domino Designer 9.0.1 FP6, ExtLib 17; we are working in a team where each one of us is coding in their own local replica, then replicating into the "hub" replica. I can't prove it but I assume that there is a connection between one of us replicating updates and the creation of new prüperty duplicates
EDIT: some more observations: I think I was able to pin it down to the replication between two specific machines; I just ran a sequence of 5 or 6 manually driven replications between both instances, every time without making any changes to the design code on either side. nevertheless every replication reported exactly 1 update and 1 addition, and each time a new property file was added.
So meanwhile I deleted the custom control in question and rebuilt it from scratch under a slightly different name (just to be on the safe side). For now it seems that the application is "behaving" now but I'm sort of sure that this will return sooner or later.
Speak after me: source control and replication do not match.
More details:
The property files get stored as attachments in a design note. That's usually the note with the form. Unless you switch on multi lingual, then each property gets its own note. When different people work on the database these note elements get recreated on build getting the next UNID kind of.
So the right flow for what you try to do: pick your best version of the nsf. Nuke the other replicas. Bind it to version control. Let your peer developer create an nsf from that repository. Sync of design shall only happen via that repository.
While your on it: add Bavarian as language, so your Munich customers can use the app too
We are currently in the process of upgrading from TFS 2008 to TFS 2012. When TFS 2008 was set up, the people involved didn't understand a lot of what the work item fields were for, and we ended up with very heavily customised templates and in fact lost a lot of default fields. As part of the upgrade to 2012 we are trying to return to the out of the box templates as much as possible to ensure we get to use as many of the features as possible, however there are a small number of custom fields that we need to include for reporting purposes.
Our product development process involves a roadmap for upcoming releases which includes new work as well as bug fixes. When a bug is assigned to be worked on by the developers we would like to be able to choose which release we're targeting the fix for - as far as I can see, Iteration is best suited for this. At the point the bug is closed though, we would also like to track what release it was actually fixed in, since things often get bumped from one release to the next if higher priority bugs or change requests come in, but this is where we come unstuck since I can't seem to assign Iteration to both fields such that the two show different values.
If possible we would prefer not to have global lists that have to be constantly updated with release numbers across our product range (we have around 8 different products which are constantly in development, each with their own release numbers), and leaving one of them as a text field leaves open the possibility that we will get inconsistencies in what people enter, eg 1.01 versus 1.1 which will show up in reporting as 2 different releases. As the fields are just looking up a set of values in the background, is there no way that the iteration list can be used twice? Or does someone have an alternative suggestion as to how we get round this?
What I think I'd suggest in this case is using a COPY rule on a state change event, so that when you move your work item into the Closed state, it would populate your custom field with the value currently in your Iteration field.
This would give you a snapshot of the value at the right point in time which then wouldn't be altered if the iteration was later changed, along with a history entry if it was opened & closed multiple times over its lifetime.
As iteration is time limited and release is perpetual there is an inherent mismatch of purpose with using iteration here. Iteration is for planning.
You would be better creating a release list with the version that you release.
If you are sprinting for example you may not know up front which release you will end up on before you start. If you are not sprinting then you are just kidding yourself that your know.
We are a software product company and our product codebase naturally gets branched for different projects. We currently use TFS2008 configured to store documents in SharePoint 2007. Both of these will be updated to 2010 versions, starting with TFS.
We'd like to branch - and not just version - our specifications so that any release from any code branch can be tested against a matching version of the spec.
It seems to me that we can either:
Keep our specs in SharePoint, using SharePoint search and versioning, and fake the branching issue by use of naming conventions or subdirectories
Move our documents from SharePoint into TFS proper. Enjoy the free versioning and branching, and quietly mourn our lost SharePoint document management goodness
Find some magic plug-in that gives us the best of both worlds?
Does anyone have any experience of any of these options?
Using SharePoint is a big advantage because it is easy to access\
Having the documents in TFS is a big advantage because the code and documentation are synced per version
It really depends on what your real needs are. If you have a shop where you have many people who have to access the documents only once in a while, probably the SharePoint advantage wins over the sync feature in TFS.
If you only have a few business analists, then probably the sync feature wins over SharePoint.
Be aware that when you store the documents in TFS, you need a CAL for every user that accesses the documentation.
I think I would go for alternative 1 by considering this: If your documentation is e.g. in MS Word, branching will give you nothing in terms of merging. That will never work with binary files.
If your documentation actually are text-based documents, I think I'd still go for 1, considering search capabilities, views etc. that you get in Sharepoint.
Here's what I've proposed as a solution, based on the answers here and on further experimentation.
First, some more background:
You can do very usable comparisons [1] between versions of a Word 2007 document held in SharePoint from inside Word (menu:Review > Compare > Compare > Specific Version...) and [2] between different versions of a Word document as separate files (menu:Review > Compare > Compare > Compare...) but you can't do version comparisons directly in TFS because it barfs on binaries.
This leaves you with an easy work-round for comparing the same document between TFS branches because both versions of the document are there on your file system (since TFS 2008 implements branching via directories) so you just use option [2] above. It also gives you a less easy work-round for comparing different versions in the same branch (or non-current versions generally) - you download the non-current versions as re-named files, then do the file comparison as before.
Now the proposal:
So I'm simply proposing we do all our specification creation in SharePoint, and create a branch folder-tree there to mirror the branch folders in TFS.
If the requirement arises, we can copy a snapshot of the related specs into TFS when the branch is released, but I'm hoping that either the branched specs won't change post-release date, or that if they do, SharePoint versioning will handle it well enough for us.