Upcoming Changes to CMS GitHub Repo

[Michael Babker]

Hello,

 

In an effort to help improve the contribution process and enforcement of code standards in the CMS, the PLT will be making some changes to the CMS GitHub repo after the release of 3.2 on October 22.   This will not affect the 2.5 branch.

 

After the release of 3.2, we will transition to having pull requests for the 3.x branch go to the staging branch instead of master.  All current pull requests that are opened before this date will remain valid for testing.   On November 1, all new pull requests must go to the staging branch.   During this transition period, we will update the GitHub repo so that the default merge branch is staging instead of master.   For those familiar with the process for the old Platform repo and the current Framework workflow, this is a very similar process.   Commits to staging will be picked up by our CI server and merged to master after all automated tests are run and pass.  At present, this includes the unit test suite and code style checks.   If the tests fail for any reason, the code will not be merged to master until the error(s) are corrected.  We will continue the automated synchronizing to our joomla-projects repo with this same process.

 

Additionally, we will be starting a new branch based on master for next version development.  In this case, it will be called 3.5-dev.   Starting this branch now will enable us to foster collaboration on the next version's development with the aim of merging next version code when it's ready instead of waiting until closer to the next version's release when the master branch is transitioned, helping to prevent a situation where a large number of features are being proposed and reviewed in a short period of time before the next version's release.  This same model will be followed for future releases as well.   The CMS maintainers will be responsible for synchronizing this branch with master and resolving any merge conflicts instead of automating synchronization on this branch.

 

If there are any questions, comments, or concerns about these changes, please address them in this thread.

[Donald Gilbert]

Fantastic news. :)

[El KuKu]

Good one :)

[Dmitry Rekun]

Awesome :)

[Samuel Mehrbrodt]

Hi,
I have a pull request for the master branch open currently: https://github.com/joomla/joomla-cms/pull/2325
It's a new feature that should go into the next major release if everything is ok with it.

Do I need to change the pull request so it's against the staging branch?
Also, as there is a long list of unreviewed pull requests, who does review them?

Thanks
Samuel

[Nick Savov]

Hi Samuel,

Yes, please switch it so that it's against the staging branch.

As to review, it's anyone from the Joomla community that would like to
review them, so you're welcomed and encouraged to take a look at other
PR's and see if there's any that interest you. Generally, each fix and
each feature requires at least two good tests. If a fix or feature gets
two good tests, then it's set to Ready for Review, at which point one of
the maintainers takes a final review before the code is committed.

Hope this helps! And thanks for contributing to Joomla! :)

Kind regards,
Nick

[Andrew Eddie]

On Thursday, 19 September 2013 00:27:33 UTC+10, Michael Babker wrote:

Additionally, we will be starting a new branch based on master for next version development.  In this case, it will be called 3.5-dev.

Michael, since there are no new features going into 3.5, is a "dev" branch absolutely necessary. I would have thought that 3.5 would just be cut from the latest stable master, no (that is, basically bug fixing 3.2 from from now until 3.5 is released)?

Thanks in advance. 

Regards,

Andrew Eddie

[Samuel Mehrbrodt]

How would a good test look like? And what should I test for my new feature?

--
You received this message because you are subscribed to a topic in the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/joomla-dev-cms/KrmEVG5Rhvo/unsubscribe.
To unsubscribe from this group and all of its topics, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send an email to joomla-...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/groups/opt_out.

[Nick Savov]

Hi Andrew,

There might be some new features in 3.5; e.g. GSoC projects that weren't
ready for 3.2:
http://developer.joomla.org/news/565-plt-meeting-notes-august-16-2013.html

Kind regards,
Nick

> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an

[Nick Savov]

Hi Samuel,

Submitters should make sure their code is working before submitting it and
they should also submit good testing instructions. Tests are performed by
people that didn't submit the code, based off the testing instructions and
general testing of the fix/feature.

Here's an example of good testing instructions for a bug fix:

Steps to reproduce the problem and test the fix:
1) Update from 3.1.5 using any upgrade method.

2) Go to any article and save. Click on the version button and note that
nothing shows up (even though 1 new item should). Save a few time if you'd
like and retest this.

3) Do the same general process as step 2 for banners, contents, newsfeeds,
tags, user notes and weblinks, respectively.

4) Apply the fix

5) Go to any article and note that the version button is not there.

6) Do the same general process as step 5 for banners, contents, newsfeeds,
tags, user notes and weblinks, respectively.

Hope this helps!

Kind regards,
Nick

> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an

[Andrew Eddie]

On 5 November 2013 13:17, Nick Savov <ni...@iowawebcompany.com> wrote:
> Hi Andrew,
>
> There might be some new features in 3.5; e.g. GSoC projects that weren't
> ready for 3.2:
> http://developer.joomla.org/news/565-plt-meeting-notes-august-16-2013.html

So, the PLT notes are saying no new features are anticipated *except*
for GSOC projects that weren't finished by the feature freeze? Is that
right?

Regards,
Andrew Eddie

[Victor Drover]

I sure hope not. :(

Sent from my iPhone

[Mark Dexter]

Personally I think the idea of not allowing new features for 3.5 is a mistake. It will hurt the momentum we have slowly built up for getting new features. I think we should obviously be very careful not to introduce b/c issues in 3.5, but that does not preclude features imo. Just my .02. Mark

[Vic Drover]

Also of note: as an extension developers there were a bunch of b/c issues in 3.2, and I am hoping 3.5 is not like that.

Cheers,

Victor Drover
Founder and CEO, Anything Digital LLC (BBB Accredited)
Co-founder, Watchful.li
262-309-4140
 @AnythingDig | @watchfulli

[Hannes Papenberg]

Question: We have lots and lots of legacy issues in our code base, which
we should fix eventually and which will break b/c, although only for a
minor group of people. When can we introduce such changes then? I'm
thinking about the routing system for example.

Hannes

Am 05.11.2013 19:01, schrieb Vic Drover:
> Also of note: as an extension developers there were a bunch of b/c
> issues in 3.2, and I am hoping 3.5 is not like that.
>
> Cheers,
>
> Victor Drover
> Founder and CEO, Anything Digital LLC (BBB Accredited

> <http://www.bbb.org/milwaukee/business-reviews/computer-software-publishers-and-developers/anything-digital-llc-in-sussex-wi-1000009940/>)
> Co-founder, Watchful.li <https://watchful.li/>
> 262-309-4140
> @AnythingDig <https://twitter.com/AnythingDig> | @watchfulli
> <https://twitter.com/watchfulli>

>
>
>
> On Tue, Nov 5, 2013 at 11:05 AM, Mark Dexter <dexter...@gmail.com
> <mailto:dexter...@gmail.com>> wrote:
>
> Personally I think the idea of not allowing new features for 3.5
> is a mistake. It will hurt the momentum we have slowly built up
> for getting new features. I think we should obviously be very
> careful not to introduce b/c issues in 3.5, but that does not
> preclude features imo. Just my .02. Mark
>
>
> On Tue, Nov 5, 2013 at 8:23 AM, Victor Drover

> <ad...@anything-digital.com <mailto:ad...@anything-digital.com>>

> wrote:
>
> I sure hope not. :(
>
> Sent from my iPhone
>
> > On Nov 4, 2013, at 10:56 PM, Andrew Eddie

> <mamb...@gmail.com <mailto:mamb...@gmail.com>> wrote:
> >
> >> On 5 November 2013 13:17, Nick Savov

> <ni...@iowawebcompany.com <mailto:ni...@iowawebcompany.com>> wrote:
> >> Hi Andrew,
> >>
> >> There might be some new features in 3.5; e.g. GSoC projects
> that weren't
> >> ready for 3.2:
> >>
> http://developer.joomla.org/news/565-plt-meeting-notes-august-16-2013.html
> >
> > So, the PLT notes are saying no new features are anticipated
> *except*
> > for GSOC projects that weren't finished by the feature
> freeze? Is that
> > right?
> >
> > Regards,
> > Andrew Eddie
> >
> > --
> > You received this message because you are subscribed to the
> Google Groups "Joomla! CMS Development" group.
> > To unsubscribe from this group and stop receiving emails
> from it, send an email to
> joomla-dev-cm...@googlegroups.com

> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com>.

> > To post to this group, send an email to
> joomla-...@googlegroups.com

> <mailto:joomla-...@googlegroups.com>.

> > Visit this group at
> http://groups.google.com/group/joomla-dev-cms.
> > For more options, visit
> https://groups.google.com/groups/opt_out.
>
> --
> You received this message because you are subscribed to the
> Google Groups "Joomla! CMS Development" group.
> To unsubscribe from this group and stop receiving emails from
> it, send an email to
> joomla-dev-cm...@googlegroups.com

> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com>.

> To post to this group, send an email to
> joomla-...@googlegroups.com

> <mailto:joomla-...@googlegroups.com>.

> Visit this group at http://groups.google.com/group/joomla-dev-cms.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Joomla! CMS Development" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to joomla-dev-cm...@googlegroups.com

> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com>.

> To post to this group, send an email to
> joomla-...@googlegroups.com

> <mailto:joomla-...@googlegroups.com>.

[Mark Dexter]

My understanding is that we can break b/c in 4.0. Mark

[Andrew Eddie]

On 6 November 2013 02:23, Victor Drover <ad...@anything-digital.com> wrote:
> I sure hope not. :(

My understanding of the change to include 3.2 was so that you had 6
months of buffer to fix bugs, and then 3.5 went into long term
maintenance which means you fix security issues and major bugs. The
previous arrangement, if I remember correctly, would be releasing 3.5
this week and have full maintenance for 6 months and then drop bad to
security maintenance when 4.0 is released.

Therefore, it is not a good idea to add new features during the time
you are trying to stabilise something that you want to keep stable.
That the whole point of the LTS strategy. I respect the PLT's right to
be flexible with GSOC and while it seems like a nobel idea, like Mark,
I think it's a mistake. Either insert a 3.3 if you want to cater for
the GSOC students and others, which I would fully support anyway, or
stick to the rules.

Regards,
Andrew Eddie

[Andrew Eddie]

On 6 November 2013 04:01, Vic Drover <ad...@anything-digital.com> wrote:

Also of note: as an extension developers there were a bunch of b/c issues in 3.2, and I am hoping 3.5 is not like that.

So how will you turn your 'hope' gets turned into 'reality'? Here's a few suggestions:

1. As an extension developer, do your bit to help make Joomla better (after all, you are building on infrastructure that you get for free) and report the issue.

2. If you can spare the internal resources, go the extra mile and try to devise a fix for the issue.

3. Test your extensions against the pre-release versions that are distributed. Return to point 1 when you find an issue.

Regards,

Andrew Eddie

[Mark Dexter]

I think my statement was misunderstood. I am in favor of continuing to add features to 3.5, not to freeze them. So I think it's good to include the GSOC projects as well as other relatively safe (from a b/c point of view) enhancements for 3.5. Obviously, this is something where people can reasonably disagree. So this is just my .02. I'm strongly biased in favor of new features. The problems we have with b/c with 2.5, for example, were totally unrelated to any new features. They were a last-minute platform change iirc. Again, this is just my .02. Mark

--

[Andrew Eddie]

On 6 November 2013 08:41, Mark Dexter <dexter...@gmail.com> wrote:
> I think my statement was misunderstood. I am in favor of continuing to add
> features to 3.5, not to freeze them.

But what does the maintenance level look like for 3.5 then? I thought
we tried to avoid having the situation where you were supporting two
versions, for example 3.5 and 4.0, concurrently for an extended period
of time (ie, six months)?

Regards,
Andrew Eddie

[Chad Windnagle]

I just wanted to chip in on the GSoC item since it's come up.

I thank the PLT for making the concession to include things, but like Andrew I'd rather see us add a .3 release to get it in 'properly' rather than bend the rules. One of my hopes / dreams for next year's GSoC is better coordination with the release cycle and with GSoC. The issue we have here is that GSoC has very determined guidelines independant of Joomla's release cycle, and the mismatch caused a lot of unclear direction for the students doing the work. 

Now that we're much more aware of this issue, next year I hope those running GSoC can coordinate closer with the PLT to prevent it from happening again.

-Chad

Regards,
Chad Windnagle

[Andrew Eddie]

On 6 November 2013 08:45, Chad Windnagle <drmm...@gmail.com> wrote:
> I thank the PLT for making the concession to include things, but like Andrew
> I'd rather see us add a .3 release to get it in 'properly' rather than bend
> the rules.

I'd have no problem with the .3 being off calendar as well. When the
GSOC code is ready, and if it appropriate, merge it and cut 3.3. Bam.
Reset the date for 3.5 and you are away. No need to bend the rules for
some and then have other people complain and moan "you merged 'his'
but not 'mine' whaa whaa whaa".

Regards,
Andrew Eddie

[Nick Savov]

Yes, that's correct.

For what it's worth, I also personally share the same opinion as Mark. At
the very least, I hope we can open up development for 4.0 in the very near
future, so that people are able to contribute their code, designs, etc,
and have an area to innovate.

Kind regards,
Nick

[Nick Savov]

+1, please exercise your right to test extensions against pre-releases.
There were over 375 bugs fixed since Joomla 3.1.5 and with that many fixes
(and new features), there are likely to be some regressions. We did our
best to not introduce breaks in backward compatibility and, if any did
occur, they were on accident.

FWIW, Joomla 3.2 alpha was released about 3 months ago and we released a
lot of pre-releases prior to 3.2.0 stable:
http://developer.joomla.org/news/566-joomla-3-2-alpha-released.html
http://www.joomla.org/announcements/release-news/5511-joomla-3-2-beta1-released.html
http://www.joomla.org/announcements/release-news/5513-joomla-3-2-beta2-released.html
http://www.joomla.org/announcements/release-news/5514-joomla-3-2-rc-released.html

We also put out announcements in the mailinglists and other channels
asking all developers to test.

Furthermore, we make all our code very accessible (except for security
fixes, for obvious reasons) and you can find the latest development
version at https://github.com/joomla/joomla-cms 24/7 all year around.

Also, please understand that with new releases there is progress being
made. If we had the mentality of not releasing new versions for fear of
regressions, we'd still be in Joomla 1.0.0. We put in place reasonable
safe-guards to mitigate regressions and do our best to not introduce
issues. We're also exploring other ways to mitigate issues and, if you'd
like to help, we'd welcome your help in this area.

By the way, statements like "extension developers there were a bunch of
b/c issues in 3.2" are not very helpful. It would be helpful to know which
issues and give examples, as I'm not aware of there being a bunch of b/c
issues in 3.2. If you've spotted some regressions, please report them
using the following process:
http://docs.joomla.org/Filing_bugs_and_issues

Thanks in advance!

Kind regards,
Nick

[Nick Savov]

Great questions, Andrew! (also great questions from everyone else too)

Maintenance for Joomla 3.5 (if released in September 2014) would continue
until the end of 2016. As an LTS, it would get updates for bug fixes (high
priority ones) and security fixes, but it would not have any new features.
Only during the security period (last 6-9 months of its life) would it get
only security fixes.

Thus, under the development strategy
(http://developer.joomla.org/cms/development-strategy.html), we're
supporting at least 2 versions no matter what, however the LTS version
only in a limited degree.

As to why x.2 releases were added, check out:
https://groups.google.com/forum/#!topic/joomla-dev-cms/vZi4gAGiSxY

As far as maintenance and x.2, it basically boils down to having an extra
6 months, never having the x.5 release be the active development branch,
and x.2 serving as a buffer for forward compatibility additions.

Kind regards,
Nick

> On 6 November 2013 08:41, Mark Dexter <dexter...@gmail.com> wrote:
>> I think my statement was misunderstood. I am in favor of continuing to add
>> features to 3.5, not to freeze them.

> But what does the maintenance level look like for 3.5 then? I thought we
tried to avoid having the situation where you were supporting two
versions, for example 3.5 and 4.0, concurrently for an extended period
of time (ie, six months)?

[Andrew Eddie]

On 7 November 2013 14:40, Nick Savov <ni...@iowawebcompany.com> wrote:
> Great questions, Andrew! (also great questions from everyone else too)
>
> Maintenance for Joomla 3.5 (if released in September 2014) would continue
> until the end of 2016. As an LTS, it would get updates for bug fixes (high
> priority ones) and security fixes, but it would not have any new features.
> Only during the security period (last 6-9 months of its life) would it get
> only security fixes.
>
> Thus, under the development strategy
> (http://developer.joomla.org/cms/development-strategy.html), we're
> supporting at least 2 versions no matter what, however the LTS version
> only in a limited degree.
>
> As to why x.2 releases were added, check out:
> https://groups.google.com/forum/#!topic/joomla-dev-cms/vZi4gAGiSxY
>
> As far as maintenance and x.2, it basically boils down to having an extra
> 6 months, never having the x.5 release be the active development branch,
> and x.2 serving as a buffer for forward compatibility additions.

I just had in my head that the time between 3.2 and 3.5 was for
stabilising the new features rather than 3.5 being on full support for
6 months and downgrading to LTS when the next major release came out.
Not quite sure why I thought that ...

Anyway, I still think you should be ruthlessly strict about no new
features in 3.5 because it's going straight into LTS. Or, revise the
development strategy, which is my preferred option :)

Regards,
Andrew Eddie

[Robert Vining]

It was pretty clear to me that 3.2 was the last release for Features in the 3.x series unless it was GSOC code that was late to the party.

This was published in the August 16th PLT Meeting Notes:

http://developer.joomla.org/news/565-plt-meeting-notes-august-16-2013.html

/** Quote **/

Joomla 3.2

4. Ideally 3.2 will be as stable as it was 2.5 in the sense that from 3.2 to 3.5 we plan not to add features but concentrate in maintenance (fixing bugs). That will give time to people to think deep in what we want for Joomla 4.0. Last time we had very little time from Joomla 2.5 until 3.0. So now we will have the time starting in 3.2. and passing through 3.5 before releasing 4.0.

/** End Quote **/

[kisswebdesign]

+1 for a 3.3 release.

It makes it easier to manage the migrations if there is time to get to know the new features before a LTS release.

It helps when building a training plan, or docs, if there is a pre-lts release to play with.

I want the gsoc code to be in 3.5, but I would be happier if I could see, use and test the new features in an official release before 3.5. As opposed to pulling the code at some point between now and 3.5 and hoping I picked the right point.

It gives everyone a common reference point if there is a specific release for the new features. And makes discussions about compatibility or bugs much easier.

Working on an alpha, beta or rc release isn't the same as an official release, and doesn't get the same number of installs by the wider community - and we want to find out as much as possible as early as possible, so that the LTS release starts off as stable as possible.

You could call the gsoc release
3.2.<latest number> (not ideal as new features shouldn't be added in a patch release)
Or
3.2.gsoc (breaks release naming convention, but makes the purpose very obvious)
Or
3.3 (sounds right, looks right, feels right)
A rose by any other name...

My £0.02