Hi Ivan, you are right our community is different... probably we will be never (or not in a short/medium time) able to manage 3 real maintenance versions but we have a least 2 active versions, the 4.x and the next one (5.0 snapshot). According to this workflow it looks better manage bugs as PR against 4.x than as PR against the master. In this way if we miss to merge something to the master we can do it later also in one go for multiple patches/bug fixes. The opposite direction is not so easy as it requires cherry pick and is "untracked" by git, so we need to assure by ourself that we don't miss bug fix. Also the famous GitFlow branching model http://nvie.com/posts/a-successful-git-branching-model/ suggest to work on the maintenance branch and after merge that in the develop branch (in our case the master).
Andrea Il 23/01/2014 12.36, helix84 ha scritto: > Hi Andrea, > > I don't think this workflow would currently work for us. The reason is > that we're letting bugs sit for too long before we get to them. I bet > you can still find bugs filed against DSpace 1.5 that were never > fixed. Even patches tend to sit for a long time before we review them. > As I see it, it would happen quite often that a PR would be filed > today against the 1_8_x branch. When we finally resolve it in 2 years > (unfortunately, this is really not uncommon for us), that branch will > be long unsupported and the oldest supported branch in that time will > be 4_x. That will require one more task. So much for the > disadvantages. > > As for advantages, I don't really see any. There's not really a > difference in porting effort in one direction or the other (e.g. 3->4 > vs. 4->3). As a developer, you're probably already working on a branch > close to master, so it's easier for you to just fix things in the > current DSpace version than check out an older one, fix it there and > build it; no advantage there, either. > > Moreover, we declared the last 3 releases supported for security bug > fixes. We didn't say anything about bug fix support. After a new major > version is released, it's very rare for us to release a minor version > of the previous release. > > There's a lot we would have to improve in our processes (time to fix > bugs, actual support for previous releases) before we could consider > this change in Git workflow. > > > Regards, > ~~helix84 > > Compulsory reading: DSpace Mailing List Etiquette > https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette -- Andrea Bollini Dipartimento Servizi e Soluzioni per l'Amministrazione Universitaria Divisione Ricerca Via dei Tizii, 6 00185 Roma, Italy tel. +39 06 44 486 087 - mob. +39 348 82 77 525 http://www.cineca.it ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
