Uploaded image for project: 'PUBLIC - Liferay Portal Community Edition'
  1. PUBLIC - Liferay Portal Community Edition
  2. LPS-87687

As a developer I would like to distinguish the last upgrade we released in previous versions of Liferay to define schemaVersions properly

    Details

      Description

      It is really common to create upgrade processes for new features as micro schemaVersion (the only ones which can be backporteable) at the end of the current list of upgrade process for a module. This is problematic since we don't reserve schemaVersions for those bugs which require an upgrade process and need to be backported. This causes problem to keep schemaVersion changes synchronized among all branches.

      Let's see an example:

      • Master, where UpgradeDLConfiguration was designed only for a future Liferay version:
        public void register(Registry registry) {
        	registry.register("0.0.0", "1.0.0", new DummyUpgradeStep());
        
        	registry.register("0.0.1", "1.0.0", new UpgradeDocumentLibrary(_store));
        
        	registry.register("1.0.0", "1.0.1", new UpgradeDLFileShortcut());
        
        	registry.register(
        		"1.0.1", "1.0.2",
        		new UpgradeDLConfiguration(_prefsPropsToConfigurationUpgradeHelper));
        }
        
      • 7.1.x:
        public void register(Registry registry) {
        	registry.register("0.0.0", "1.0.0", new DummyUpgradeStep());
        
        	registry.register("0.0.1", "1.0.0", new UpgradeDocumentLibrary(_store));
        
        	registry.register("1.0.0", "1.0.1", new UpgradeDLFileShortcut());
        }
        
      • Now we need to add an upgrade process to solve a bug in master/7.1.x:
        public void register(Registry registry) {
        	registry.register("0.0.0", "1.0.0", new DummyUpgradeStep());
        
        	registry.register("0.0.1", "1.0.0", new UpgradeDocumentLibrary(_store));
        
        	registry.register("1.0.0", "1.0.1", new UpgradeDLFileShortcut());
        
        	registry.register(
        		"1.0.1", "1.0.2",
        		new UpgradeDLConfiguration(_prefsPropsToConfigurationUpgradeHelper));
        
                registry.register(
        		"1.0.2", "1.0.3",new UpgradeSolveBug());
        }
        

      But then we realize that we need to reorder the upgrades processes to be able to backport it to 7.1.x. That's really problematic sometimes.

      Proposal:
      1) Create a SF rule which checks the LPS, if it is a new feature, story or improvement, new upgrade processes have to be defined as a major change in the schemaVersion.

      or

      2) Create dummyUpgradeSteps called dummyRelease71 or similar which increases the schemaVersion to the next minor value in all modules with upgrade processes to help developers to distinguish where they should add the new upgrade process for every case.

      Taking the previous example, we should get something like this in master

      public void register(Registry registry) {
      	registry.register("0.0.0", "1.0.0", new DummyUpgradeStep());
      
      	registry.register("0.0.1", "1.0.0", new UpgradeDocumentLibrary(_store));
      
      	registry.register("1.0.0", "1.0.1", new UpgradeDLFileShortcut());
      
              registry.register(
      		"1.0.1", "1.0.2",new UpgradeSolveBug());
      
      	registry.register("1.0.2", "1.1.0", new dummyRelease71());
      
      	registry.register(
      		"1.1.0", "1.1.1",
      		new UpgradeDLConfiguration(_prefsPropsToConfigurationUpgradeHelper));
      
      }
      

      And this in 7.1:

      public void register(Registry registry) {
      	registry.register("0.0.0", "1.0.0", new DummyUpgradeStep());
      
      	registry.register("0.0.1", "1.0.0", new UpgradeDocumentLibrary(_store));
      
      	registry.register("1.0.0", "1.0.1", new UpgradeDLFileShortcut());
      
              registry.register(
      		"1.0.1", "1.0.2",new UpgradeSolveBug());
      }
      

      Anyway, other options to solve this issue can be analyzed.

        Attachments

          Activity

            People

            Assignee:
            support-lep@liferay.com SE Support
            Reporter:
            alberto.chaparro Alberto Chaparro
            Recent user:
            Marta Elicegui
            Participants of an Issue:
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Dates

              Created:
              Updated:

                Packages

                Version Package