The fact that .LRN and OpenACS are in different repositories has substantially complicated all tagging and updating work. It is not a trivial thing to work around, and causes problems in many different operations.

--------------------------------------------------------------
Translations:
I had to do some CVS juggling to get the translations loaded properly.  In order to get the correct, released code onto the translation server (and not put buggy HEAD core on it), the files must be updated with the openacs-5-0-compat tag.  However, the updated translation catalog files cannot be committed back to CVS while they are tagged openacs-5-0-compat, so I had to retag them all oacs-5-0 (for core) or HEAD (for the rest) or dotlrn-2-0 (for .LRN) before committing the catalogs.  I also had to add a number of new catalogs to CVS for new language/package combinations.  Then I had to re-update everything back to openacs-5-0-compat to get the newest code so I could upgrade the translation server to the new version.

--------------------------------------------------------------
Version Numbers:
I used a combination of perl and emacs and manual labor to replace the version numbers for all .LRN packages to 2.0.2.

sloan-bboard was copied from bboard, but the version numbers were taken intact.  Since it was at 4.0.2b6, I can't change it to 2.0.2 to match the rest of .lrn.  I set it to 4.0.3.
Several dotlrn packages, the recruiting-related ones, were missing <provides> statements so I added those.

I used a bash/perl statement to change release date on all dotlrn packages and acs-core packages to 2004-03-10

dotlrn-wps wasn't branched properly - I skipped it.  If it's in active use it can be fixed and made part of 2.0.2 later.

I did not re-version any of the OpenACS packages in dotlrn-prereq.  Only calender, which Dirk gave a new version number, will upgrade automatically.  As far as I know, there are no critical bugs in the other packages that must be fixed by upgrade.  These packages all have their own packages numbers independent of core, and developers who work on these packages are responsible for versioning them. At a minimum, you should increment the dot version number each time you put in bug fixes (eg., 2.0.3 becomes 2.0.4).  These version numbers are unrelated to either Core or .LRN.  You should also move the openacs-5-0-compat flag to the new version when you work on these packages.

At this point I believe that all of the CVS files for OpenACS-core and .LRN have the right data, in the right branches, with the right version and release date.  The dotlrn-prereq files, however, have the correct translations on the wrong branch (HEAD instead of oacs-5-0) and until I correct this .LRN 2.0.2 cannot be released.

--------------------------------------------------------------
Mistakes
I had to correct several mistakes that I made as I went along, so if you upgraded from repository between Monday, 8 March 2004, and now, you probably didn't get the new translations.  Hopefully this didn't happen to anybody - it should be fairly easy to fix if it did happen, even on a production system.

Mistake one was that I committed the dotlrn-prereq translations to HEAD instead of oacs-5-0.  The underlying problem is how we manage all of those prereq packages.  They get released in a batch, and they get translated in a batch, but in general we want them to be maintained singly, as Dirk did when he fixed bugs in calendar.  So we need a way for people working on single packages to get the translations out of the server.  I have not yet corrected this problem.

Mistake two was using the /web/translate directory as my working directory for the cvs work, when it also serves the translation server.  This meant that as I moved files back and forth between HEAD and branches, I broke parts of the translation server.  A better approach is probably to clone the translation server and then work from that cloned database on a clean checkout.  However, that may cause inconsistencies in the merging, so another approach may be to work from a cloned file system but use the live database.
  I will try this approach while I correct mistake #1.

Other, corrected, mistakes include not getting the dotlrn translations into dotlrn-2-0 the first time, so for a while there was a 2.0.2 tag, which had new version numbers but not new translations.

In the University of Valencia we are updated the .LRN 2.0.1 to .LRN
2.0.2 with 40.000 users and 200 classes.

Now, when we go to "My Space" the system takes 6 sg. in showing the page

We are actived the Developer Support and the problem this in the function acs-permissions-cretae.sql

Somebody can help us.


--------Information by Developer Support---------------

4389 ms        dbqd.dotlrn.www.dotlrn-main-
portlet.select_communities: select nsdb0
            select dotlrn_communities_all.*,
                  dotlrn_community__url
(dotlrn_communities_all.community_id) as url,
                  (CASE
                      WHEN
                        dotlrn_communities_all.community_type
= 'dotlrn_community'
                      THEN 'dotlrn_community'
                      WHEN dotlrn_communities_all.community_type
= 'dotlrn_club'
                      THEN 'dotlrn_club'
                      ELSE 'dotlrn_class_instance'
                  END) as simple_community_type,
                  tree_level(dotlrn_communities_all.tree_sortkey) as
tree_level,
                  coalesce((select tree_level
(dotlrn_community_types.tree_sortkey)
                        from dotlrn_community_types
                        where dotlrn_community_types.community_type =
dotlrn_communities_all.community_type), 0) as community_type_level,
                  acs_permission__permission_p
(dotlrn_communities_all.community_id, '3045612', 'admin') as admin_p
            from dotlrn_communities_all,
                dotlrn_member_rels_approved
            where dotlrn_communities_all.community_id =
dotlrn_member_rels_approved.community_id
            and dotlrn_member_rels_approved.user_id = '3045612'
            order by dotlrn_communities_all.tree_sortkey