File: maintainance.txt

package info (click to toggle)
ecflow 5.15.2-2
  • links: PTS, VCS
  • area: main
  • in suites: forky, sid
  • size: 51,868 kB
  • sloc: cpp: 269,341; python: 22,756; sh: 3,609; perl: 770; xml: 333; f90: 204; ansic: 141; makefile: 70
file content (71 lines) | stat: -rw-r--r-- 2,168 bytes parent folder | download | duplicates (3)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
Changing Python version
==================================================

Update file(s):

o $HOME/.user_kshrc
o Change $WK/build_scripts/nightly/build.py
o Change $WK/build_scripts/site_config/*
o Change $WK/build_scripts/install_ecflow.sh

Changing Boost version
==================================================

Update file(s):

o $HOME/.user_kshrc
o Change $WK/build_scripts/nightly/build.py


Updating version number
======================================================

- change version in $WK/VERSION.cmake
- run  $WK/cmake.sh
- check in the generated files.


Making a release
====================================================

Do NOT link on your local machine, use the nightly build
otherwise the embedded paths in ecflow.so  will be wrong.
We use embedded paths to avoid user having to set LD_LIBRARY_PATH

After each release, make sure the ecflow tar file is
copied to $SCRATCH and inform Daniel. This will allow
him to make rpm packages, build on other linux flavours.

This is important, so that release, used internally is in
sync with release given to users.


Documentation
=============
The ecflow extension is documented using sphinx.
The actually doc strings should use Rest formatting to
correctly appear in the generated documentation.

Migration
======================================================================
The release number has the format <release>.<major>.<minor>
Change in major and minor numbers means that the check point
file are compatible.

From 3.0.1 we have provides a mechanism to migrate to all future version.
irrespective of check point files.  

    ecflow_client --migrate > defs_with_state.def

The file 'def_with_state.def' is normal ascii definition file, where
all the state information is written as comments. This can then
be loaded in a future release by calling:

   ecflow_client --load defs_with_state.def
   
If there are problems with 'defs_with_state.def', (See ecflow_migrate.py)
these can be handled with ecflow_migrate.py :
    
   python  4.5.0/bin/ecflow_migrate.py/ecflow_migrate.py --d  ./defs_with_state.def # -> defs_with_state.def.mig
   ecflow_client --load defs_with_state.def.mig