nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Set component versions via command line

prof_brazen_guff

Hi there

I'm using LS 3.1 and have a requirement to manually set component version numbers to, say, 1000. I've tried iwextattr, but the version no. doesn't seem to be one of the extended attributes available for modification.

Is there a clt that I can use to do this? If not, has anyone done anything similar via another means?

Thanks in advance for your help

Paul

Find more posts tagged with

Comments

tec_iwov

there is no specific API as it not recomended you change the version numbers. This effects GCL and in newer versions Dependency management.

Can you use iwsubmit CLT?

birt output 2.JPG

prof_brazen_guff

Hi both

Thanks v much for the responses.

dobrien - I guess I could write a script to run iwsubmit multiple times because I want all components to begin with the same version no., so thanks for the suggestion.

tech_iwov - I'm trying to do this based on advice provided by a trusted consultant in order to allow us to use a development environment in conjunction with our production environment - I need a way of moving content (comps/templates/pages etc.) from one to another, and he's suggested that manipulating version numbers of comps, and the versions used in the templates and pages is a way of achieving this. Is this not the case? If it's not, is there another preferred way of moving content between a dev and prod server without causing the kinds of issues with LiveSite content we've seen in the past?

Thanks again

Paul

Adam Stoller

[...]
tech_iwov - I'm trying to do this based on advice provided by a trusted consultant in order to allow us to use a development environment in conjunction with our production environment - I need a way of moving content (comps/templates/pages etc.) from one to another, and he's suggested that manipulating version numbers of comps, and the versions used in the templates and pages is a way of achieving this. Is this not the case? If it's not, is there another preferred way of moving content between a dev and prod server without causing the kinds of issues with LiveSite content we've seen in the past?

I don't know what "kinds of issues" you had with "LiveSite content ... in the past" - but depending on version numbers of all those different pieces sounds like a very fragile concept and not one that I'd want to put a lot of time and/or money into. Version numbers are just that - they represent the number of development iterations it takes to get something the way you want it - sometimes you'll be able to make a change (or new feature / functionality) in one version, sometimes it may take two, three, or more versions before you get all the bugs out your development - trying to keep all the moving pieces in sync via version number is not going to be easy or (IMO) worthwhile.

Instead - consider EDITIONs (assuming all the pieces are in the same branch) - a named edition can be used as the "source" of all the appropriate versions of a complete project. If you're working across multiple branches - using the identically (or similarly) named edition on all source branches again gives you a means of identifying a "release" of the project.

Migrating the files from DEV to QA and/or to PROD TS environments can either be done with OpenDeploy or utilities such as Beyond Compare - but for each target system - you'll have new version numbers - so the version of a file on DEV will rarely be the same as the version number of the same file on QA and/or PROD.

dobrien

SPAR is the recommended way to move content between systems. You'd want to build a .spar file, and there are some specifications on how to do that, with Support. When you build a .spar you'll manipulate the version numbers so that Get Latest works as expected.

prof_brazen_guff

Thanks again for the advice all.

ghoti - after investigating what would be required to manipulate and use version numbers, I agree that this approach isn't worth pursuing.

I have considered using editions, but the main stumbling block here is that we have a requirement to publish our content to development runtime before publishing to production runtime as, in the past, we've experienced differences in functionality and behaviour between what you see when previewing in TS, and what you see when viewing the published page. Also, we need to carry out a great deal of cross-browser testing which isn't reallly possible in TS.

dobrien - thanks. Looks like I need to do some serious investigation into SPARS as I haven't really used them before.

ChaituKNag

I am not sure about release level manipulation of component version numbers, but if you had any issue in doing "Get Latest Components" on a .page file, you can fall back to the following command (this works for Unix installations):

find [folder_path_to_pages or single_file_path] -name '*.page' | xargs perl -pi -e 's/\
What the above command does is, it changes version of each component in the page concerned to "0". You can put any number there.

Adam Stoller

It helps if you make sure the code is formatted correctly so folks can read it:

I am not sure about release level manipulation of component version numbers, but if you had any issue in doing "Get Latest Components" on a .page file, you can fall back to the following command (this works for Unix installations):

find [folder_path_to_pages or single_file_path] -name '*.page' | xargs perl -pi -e 's/\<BaseComponent Version\=\".*\"/\<BaseComponent Version\=\"0\"/g'

What the above command does is, it changes version of each component in the page concerned to "0". You can put any number there.

I make no claims on the correctness of the code (I think you may have a few more back-slashes there than necessary) - I'm only trying to make sure that what was originally written is displayed so that others can do with it as they want.

ChaituKNag

Hope this looks good.
I am not sure about release level manipulation of component version numbers, but if you had any issue in doing "Get Latest Components" on a .page file, you can fall back to the following command (this works for Unix installations):

find [folder_path_to_pages or single_file_path] -name '*.page' | xargs  perl -pi -e 's/\ 

What the above command does is, it changes version of each component in the page concerned to "0". You can put any number there.

prof_brazen_guff

Thanks - I'll check this out