In sidekick, I can create as many versions of a page and can restore as well.
What I am looking for is, how to limit the number of "creation of page versions" . Suppose, after 5 versions I want to display an error - "more versions are not allowed".
I followed the link for reference but no luck: http://www.wemblog.com/2012/08/how-to-work-with-version-in-cq.html
You have to create a osgi:Config within repository for this (com.day.cq.wcm.core.impl.VersionManagerImpl).
You can control number of version created by activation by setting versionmanager.maxNumberVersions property.
Thanks in advance
There is no pro-active way to stop any versions from being created in the AEM repository. The configuration you are referring to is from: https://docs.adobe.com/docs/en/aem/6-2/deploy/configuring/version-purging.html#Version Manager
versionmanager.maxNumberVersions (int, default 5)
on purge, any version older than the n-th newest version will be removed. If this value is less than 1, purging is not performed based on the number of versions
This is the setting for version purge task which retains a maximum of n number of versions after purging where n is the number defined in the above config.
A preemptive version disabler won't work as versions are created from background tasks like workflows asynchronously. These tasks will fail without any feedback to user which will be problematic in most scenarios.
If you want to change the sidekick and disallow version creation, then you will have to rewrite core logic of the UI which can be a big task. Version Purging is the recommended way to setup your instance to limit the number of versions.
Related
I understand that I cannot make backward incompatible changes to Workflows per:
How to make changes or fixes to Uber Cadence Workflow without breaking determinism?
However I am not sure what "backward incompatible" means here. Can I simply not deploy new code without using getVersion, period? Or as long as the history tracking that is used for restoration is compatible between the 2 versions then I can update without getVersion? Or I can update without getVersion under some under conditions?
Generally anything that can change the way the history is generated is considered backwards incompatible. The following changes are backwards compatible:
Any activity implementation.
Duration passed to sleep and timer creation function.
Changing arguments to activities.
Changing activity options and retry policies.
Changing values of variables that don't affect the workflow execution path. For example if some variable accumulates some data and this data is only used in a query.
We recommend saving a few histories and then replaying them as part of unit tests to find out about non compatible changes earlier.
We need to preserve a particular version of the pages for a certain amount of time, lets say for an year.
If we use the Version Manager and provide the 'Max Version Age' and 'Max Number Versions', it will preserve the latest x number of versions for that amount of time.
Is there a way to differentiate in the versions and preserve a particular one(NOT the latest one) for x number of days?
Or Is there any other criteria to preserve the versions other than the latest ones?
you'd just need to set max number of versions to a number below 1.
Please be cautious about the potential repository growth this represents (basically N pages times the number of times a page gets versioned in a year).
The version manager doesn't provide the granularity to preserve a specific page version beyond a certain date and/or number of versions other than disabling version management altogether. If you have a particular version of a page or site that you wish to keep beyond the scope of the version manager, you can always create a package of this content that can either be stored in the package manager or downloaded to external storage.
We're migrating over from another build tool where relied on the CI to maintain a release version that increments based on a given pattern. In VSTS, the release revision id autoincrements from 1, but we deploy to targets that require a newer version number than the current one.
I'd really rather not create hundreds of fake releases to push the version number up or have to manage the version number myself.
Is there a way to seed the release version with a starting number? Or, alternatively, is it possible for a release to modify a release plan's variable (so that the changed value is available to future releases)?
You can define custom variables, that enable you to do this.
To view, edit, and add new release definition variables, open the Variables tab of a release definition.
The Publish-UpgradedServiceFabricApplication powershell cmdlet that comes with the SF SDK has an $UnregisterUnusedVersions option that when set to $true will remove all unused app type versions. This is great as I don't want clutter building up on my clusters.
BUT, what I really want is to keep the last 3 or so versions so I have some flexibility to rollback if needed. Is there any way of doing this short of re-creating that cmdlet? I'm gonna guess the challenge is for the cmdlet knowing which ones to leave and which to remove. Perhaps using semver logic it could remove all but the most recent 3 versions?
Is this a pipe-dream? Feels like something I should be able to configure my cluster to do. Periodically purge all but the latest X versions.
The problem with this is that the type version can be any string. From SF's point of view, there is no ordering to it other than the date/time it was registered. You get to assign meaning to it in whatever way works for your applications.
Should be easy enough to script though. Use FabricClient to figure out which types have instances running and which ones you want to purge. Then turn that script into a service so it's always running and periodically purging old types.
We want to implement semantic versioning in our process, we are in version 1.0.0, and we have added two new functions. We will deliver these functions soon.
The question is: should we name our next version 1.1 or should we name it 1.2 because we have created two new functions.
In general, if we add n new functions, should we increment by n the minor component of the version, or we only increment by one in each delivery?
Version does not depend on how many functions
you have written in that particular release.
If your current version is 1.0.0 ,then
it should be 1.0.1 or 1.1 depend upon your
naming rule that you have put for your
product and dependencies.
There is no absolut right solution to version numbers.
The way most people i know do it is by increasing it on every version they plan on making available.
Microsoft themselves for example use the "major, minor, build, and revision" semantic for their version numbers. Just don't change up the way you do your version numbers after deciding on one. Because then they become useless :-)