TL;DR: +1 I¹m strongly in favor of moving to the master branch. This not only is more akin to what other Apache projects are doing, but makes it much easier for new developers to come in and help contribute code. Its very non-intuitive to fork a repo, check out a separate upstream branch, then do the development, then submit the PR and manually retarget a non-default upstream branch. Whats worse is, because we as Apache Apex, don¹t control the Github repo we can¹t retarget a PR which makes even more work for the contributing developer. In the end I¹m 100% for making it as simple as possible for the contributing developer rather than the committers and PMC members.
I get why its been done though. I think we should be able to migrate to master and still maintain the ability to tag branches (I.e. Release candidates, full releases, etc.) for backwards compatibility / maintenance releases. What features are there that we currently have as a project that would not be covered if we moved to development on the master branch? Wondering if we just need to rework the committer workflow and release cuts to accommodate these issues. Thoughts? On 1/21/16, 4:59 PM, "Sandesh Hegde" <[email protected]> wrote: >How about we just keep "devel"? and master continues to be released >version. > >On Thu, Jan 21, 2016 at 4:55 PM Vlad Rozov <[email protected]> >wrote: > >> If I remember correctly the idea behind using master and devel-3/devel-4 >> was to use devel-3 and devel-4 for trunks on 3.x and 4.x and use master >> as the latest released version. >> >> I am not proposing to use master one way or another, just stating my >> understanding behind the current configuration of the Apex core and >> malhar branches. >> >> Thank you, >> >> Vlad >> >> On 1/21/16 15:18, Thomas Weise wrote: >> > It my be possible but I would question why. The master branch does not >> > serve any other purpose, so why not use it for development? >> > >> > On Thu, Jan 21, 2016 at 2:58 PM, Vlad Rozov <[email protected]> >> wrote: >> > >> >> I guess not, I think that we don't have admin rights to manage apex >>core >> >> or malhar mirrors on github. >> >> >> >> Thank you, >> >> >> >> Vlad >> >> >> >> >> >> On 1/21/16 14:12, Pramod Immaneni wrote: >> >> >> >>> Can't we set a default branch in the repo to be different from >>master? >> >>> >> >>> On Thu, Jan 21, 2016 at 2:04 PM, David Yan <[email protected]> >> wrote: >> >>> >> >>> Hi all, >> >>>> We have been using the devel-3 branch for development in both Apex >> Core >> >>>> and >> >>>> Apex Malhar. The reason was that we wanted to have the master >>branch >> to >> >>>> point to the latest release so that when a user checks out from our >> git >> >>>> repo, it's always the latest source release and it always works. >> >>>> >> >>>> But on the other hand, from what I see, that is not what most >>active >> >>>> apache >> >>>> projects do. I checked Flink, Spark, Storm, Samza, Pig, Hive, and >> >>>> Hadoop, >> >>>> and ALL of these projects have commits on the master branch that >>are >> at >> >>>> most one day old. Apex Core on the other hand, the last commit on >>the >> >>>> master branch was Nov, 2015, and that was when we released Apex >>Core >> >>>> 3.2.0. >> >>>> >> >>>> Because of our stale master branch, it's easy for someone outside >>of >> the >> >>>> Apex community to conclude that Apex is not very active compared to >> other >> >>>> Apache projects. >> >>>> >> >>>> To me, the benefits of using the devel-3 branch are simply not >>worth >> the >> >>>> potential cost. I would like to propose that we get rid of the >> devel-3 >> >>>> branch and use the master branch for development, instead of having >> the >> >>>> master branch always reflecting the latest release. We use tags >>for >> that >> >>>> purpose. >> >>>> >> >>>> Please share your thoughts. >> >>>> >> >>>> Thanks! >> >>>> >> >>>> David >> >>>> >> >>>> >> >> ________________________________________________________ The information contained in this e-mail is confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.
