Problem/Motivation

The name YAML Form does not accurately describe this module's full use case and/or purpose.

Proposed resolution

Consider changing this module's title and/or namespace.

Pros

  • YAML is a super popular and an easy to remember acronym.
  • I was able purchase yamlform.com and yamlform.io
  • The keywords "YAML and form" has great SEO
  • This module build forms using YAML to store the form element's render array.

Cons

  • YAML sounds too technical
  • YAML scares off non developers
  • Drupal community is looking for a webform replacement

Notes

  • Drupal has history of not so great namespace like Ctools, CCK, and maybe yes also the name Drupal. The community has been better about fixing bad namespaces like changing Nodewords becoming Metatags.
  • We could keep the namespace as YAML and change the project title to "Yet Another Form Builder", BTW http://yafb.com/ is taken :)
  • Market is saturated with multiple variations of form and/or survey builder product names. http://alternativeto.net/software/webform/

Personal feeling

  • The ability to edit an entire form as YAML, is one of the most unique and powerful features within this module.
  • I love YAML and this module would never have existed without YAML.
  • I want this form builder to be site builder and developer friendly, which is also why I like the using the word YAML in this project's namespace because it is a very friendly and easy to learn markup language.

Comments

jrockowitz created an issue. See original summary.

hass’s picture

YAML is a super popular and an easy to remember acronym.

What does ist abrivate?

We could keep the namespace as YAML and change the project title to "Yet Another Form Builder", BTW http://yafb.com/ is taken :)

YAFB. You are on d.o. No extra domain is required. You can rename the project name space, too.

"Form Builder" sounds a lot better to me. No need for "yet another" unneeded tool / wheel reinvent.

jrockowitz’s picture

Yes, a very generic name like FormBuilder could work since most people will probably refer to this project as Drupal's Form Builder.

The formbuilder namespace is available. http://cgit.drupalcode.org/formbuilder

Simon Georges’s picture

Formbuilder is available, but "Form Builder" is taken, won't using this name introduce too much confusion? There's already a lot of communication around the fact that YAML Form is the new Webform, why not keep it that way?

TrevorBradley’s picture

Both "superform" and "super_form" appear to be available. YAML Form is pretty super in my opinion, superseding webform.

hass’s picture

If it replaces webform I agree that it should be done this way and committed to webform project.

mccrodp’s picture

+1 for committing to the Webform namespace if it is decided to replace Webform (and Webform will not be upgraded). If not Webform, leave at Yet Another Form Builder as there is quite a lot of issues already mentioning the YAML namespace.

jrockowitz’s picture

@quicksketch and Lullabot have invested a huge amount of time and energy in the Webform module including setting up http://webform.com. It is very likely the next version of the Webform module will happen via Back Drop. Also, there is a whole ecosystem around the Webform module which will never be compatible with YAML Form module. Therefore, I want to respect @quicksketch's past contribution to the Webform namespace within Drupal and let the Webform module continue to grow within the Backdrop community.

mccrodp’s picture

Right, makes sense if we can't easily preserve the ecosystem. I don't quite understand the Backdrop reference or how it applies here as I'm not in the loop with it, but sounds like it may be another reason to maintain separation.

jrockowitz’s picture

@quicksketch intends on continuing to support the Webform module within the Backdrop community, which means Webform 5.x would be for Backdrop (and hopefully Drupal 7.x).

hass’s picture

That means you can take over the webform namespace.

D8 requires a lot of changes and rewrites and it is clear to all developers that the webform code and integrations need to be rewritten. It is also clear that old webform plugins need to be rewritten. That is why quicksketch has left to backdrop. It is a good idea to do development now in the webform namespace and not later as old D7 code is not D8 compatible and will never be. But D9 may not require so much changes. Webform need to be rewritten, you have done it in a "sandbox". Now use the existing ecosystem to push things faster. I'm sure the plugin developers will more likely join and help as it will happen to your new projects.

We do not support backdrop here and it has itself a limited future. Just waiting for the day when it dies with 2 developers who just do not like to learn OO today...

We should not give up the webform namespace everyone knows for such reasons.

sachariew’s picture

Leave it as YAML-Form.

1. It has been a tremendous success story as "YAML-Form".

2. YAML editing is very powerful and I can rebuild and change forms way faster through YAML than through the GUI.

3. Those, who are setting up sites and creating forms are more than able to understand what YAML-Form is and how it is different to Webform. I am no coder but did create forms through Webform in D6 years ago. I had no difficulties to find out that YAML-Form is the best way to go with D8, right now.

Lastly: Thank you very much for the continued development and implementation of user wishes and inputs!

jrockowitz’s picture

Right now, I feel this might be the most immediate compromise #2808675: Refe to "YAML Form" as "Forms" and "YAML Form Submissions" as "Submissions" within Drupal's UI..

I think everyone would agree that within the Drupal UI/UX the name 'Forms' is a much more user friendly and expected title for site builders looking to build a form.

jrockowitz’s picture

Status: Active » Needs review

So I have completed #2808675: Refe to "YAML Form" as "Forms" and "YAML Form Submissions" as "Submissions" within Drupal's UI. and I think this almost completely takes care of the issue that site builders (and clients) don't know or care what a "YAML Form" is, they just want to build forms and collect submissions. I think the Drupal developer community should be okay with working and developing code within the 'YAML Form', 'YamlForm', and finally 'yamlform' namespace.

Maybe in the future when the YAML Form module has a full migration path from the Webform module, and there is no 8.x version of the Webform module, the YAML Form module should be moved to the Webform namespace (in Drupal 9.x).

I am going mark this ticket as 'Needs Review' to allow the discussion to continue and hopefully in 2 weeks I can close this ticket.

hass’s picture

Status: Needs review » Needs work

I'm asking again as I see not a single answer here to my comments.

Why the hell are you not using the webform namespace? There is no webform d8 code and the maintainer left to backdrop. We should reuse it.

fenstrat’s picture

I can see @hass' somewhat blunt point. Webform on D8 is essentially at a dead end. YAML form looks to be taking over the functionality it provided. Makes sense for it to do so in the Webform namespace.

Having said that, Webform has a lot of "baggage" (dozens of contrib modules extending it, full upgrade path from D6/7 would be required) so using it's namespace needs careful consideration.

Ultimately this decision rests with @jrockowitz as he's essentially the one doing the work.

hass’s picture

As said - none if the old addons/plugins can be used under d8 and need to be rewritten. But the developers are for sure more wilingly to do for webform d8 than for yaml forms they never heard about.

jrockowitz’s picture

Wait a second, this is @quicksketch's decision, he is the maintainer the Webform module and has a SAAS business around Webform.

Personally, right now, I don't want to have D8 YAML Form issues mixing with D7 Webform issues, especially while Webform for D7 is still under very active development.

I think the best solution is to plow ahead with #2803269: Build a migration path from D6 and D7 Webform to YAML Form and #2803269: Build a migration path from D6 and D7 Webform to YAML Form and then decide (after talking to @quicksketch) if YAML Form should become Webform for D8.

Also, I am not going to write migration path from D6/D7 Webform to YAML Form by myself.

hass’s picture

Have you asked quicksketch? He decided to leave Drupal for Backdrop... who cares. He will not maintain a D8 version. Again, issues are against rewritten code. Nothing can get mixed. We will find a way for the migration.

stefan.r’s picture

+1 to renaming this, for all of the reasons listed in "Cons" -- have we asked @quicksketch about taking the webform namespace?

fenstrat’s picture

@stefan.r I've reached out to @quicksketch as well as the active Webform 7.x maintainers @DanChadwick and @Liam Morland and asked them for their thoughts.

jrockowitz’s picture

I have to weigh in and be honest that I personally don't want the YAML Form to become the Webform. I have spent the past year working on a completely new form building solution for the Drupal community. I don't want users to assume that I am going to port and support every feature in the Webform module. And yes, I want my hard work to standout on its own and not be merged into another module.

I have a huge amount of respect for @quicksketch and Webform.com. I feel that the 'jersey' that was the 'Webform' module should be retired with Drupal 7 and live on in the BackDrop community. Also keep in mind that the Webform module for Drupal 7 and Webform.com will be around for many more years.

Personally, I am more focused on the future of form building in Drupal core and possibly pushing the YAML Form module in that direction, especially if I can integrate YAML Forms with the Field API.

@fenstrat I still want to thank you for reaching out to @quicksketch, @DanChadwick, and @LiamMorland since we do need to get their input and insight. We all owe them a beer for their work on the Webform module.

With everything I just said, I am open to renaming the YAML Form module. At the same time, the YAML Form module's usage stats are indicating that people are finding and using the module.

DanChadwick’s picture

Thanks @fenstrat for reaching out.

Reusing / usurping the webform namespace for D8 would require at a minimum the consent of @quicksketch and @jrockowitz. I am unaware of a Drupal policy that allows the hostile takeover of a branch in a non-abandoned project. There is active maintenance and development in the webform 7.x-4.x branch. @Liam Morland has agreed to take over primary maintainership, so his consent would be needed too.

It is certainly possible to filter a combined issue queue, but it is a pain, and it distorts the module statistics. This is why I routinely mark webform D8 issues as "tasks" so that they don't appear as bugs and so that I can more easily ignore them.

I certainly agree that YAMLform has much the same market position as webform. Since the hopes of a D8 port seem to have died with Acquia backing out of doing the port and @fenstrat's project being cancelled, perhaps the best solution is simply to refer Webform users from the project page to the yamlforms project page.

There is also a big need for a migration path. I believe there is a sandbox form D6 to D8. What might be better would be a D7->D8 path because someone can easily upgrate webform D6 to D7 and then move to yamlform.

I would also welcome some community documentation about differences between yaml and web form. This would help people understand whether yamlform will work for them. Perhaps there is such a thing? I would need continuous updating though.

The argumentum ad hominem directed at @quicksketch is distracting, inappropriate and offensive.

Liam Morland’s picture

I am fine with YAML Form becoming the 8.x branch of Webform and I am fine with it existing in its own project. @quicksketch and @jrockowitz would both need to agree for it to move into Webform. I agree that YAML Form is not a name that would appeal to less technical people; it sounds like some specialized kind of form, rather than the form module most people would want to use.

I note that the "form" namespace has not much in it and what is there is from D6. Perhaps that could be reused.

fenstrat’s picture

Thanks @DanChadwick and @Liam Morland for your replies.

I wouldn't call this a hostile take over of the Webform name space, instead it is renaming @jrockowitz's great work in YAML form to reuse the much more friendly (and available) Webform namespace for D8.

Re the Form namespace, there is a thought for the core Contact module to rename and use that space, so I think it's best left alone.

I've asked @quicksketch again if he could chime in here.

quicksketch’s picture

Hi guys, sorry somehow I ended up at #2822361: Link to YAML Form project(and other alternitives?) for Drupal 8 on project page instead of this issue and ultimately suggested the same thing. I built up a new pro/con list in that issue that I'll repost here. Several of those points have been mentioned here already:

Pros:

  1. YAML Form provides most (and is working on covering all) the functionality of Webform.
  2. The "Webform" namespace is (subjectively) better and well-known name.
  3. A "port" of Webform, a module with 500,000 installs, would boost the adoption and reduce hesitancy around Drupal 8.
  4. An in-development migration path exists to move existing users to YAML Form.
  5. Claiming the Webform namespace would also likely increase adoption of the module.

Cons:

  1. Renaming the module would take a development effort, and existing users would need to eventually replace the module with the webform-namespaced version.
  2. YAML Form is not actually a port of Webform, and is completely API-incompatible.
  3. The migration path is not complete, most notably the submissions themselves are not migrated.
  4. Although feature-equivalent, the UIs are similar but not really the same. This could cause confusion for users expecting it to be identical.

As for my personal take on this, I would be happy to see Webform have a continued existence in the world of Drupal. If YAML Form were to claim the namespace, then it would provide at least the appearance of continuity. I believe it would also make the Webform developers feel that their work for the last decade didn't reach a dead end.

@jrockowitz has done an incredible amount of work making YAML Form, and if he were up for the renaming, I would be happy to transfer the project node ownership over to him (with the approval of Liam and Dan).

DanChadwick’s picture

One one-time task would be to close all existing webform 8.x issues. Shouldn't be more than an hour or two, I'd think, unless we can d.o to do it for us. yamlform could then be webform (perhaps) 8.x-2.x.

@Liam Morland and @jrockowtiz would then have to filter the issue searches. I did this extensively. It's not totally terrible, especially if you bookmark a meaningful query.

Liam Morland’s picture

I don't mind filtering the issues. I support @quicksketch's proposal.

jrockowitz’s picture

@quicksketch (and fellow webform maintainers) I am completely honored that you are open to having the YAML Form module continue the Webform module's legacy.

The more I thought about this thread, the more I realized that I never really intended to be the maintainer of the Webform module. Honestly, if I had wanted to be the maintainer of the Webform module, I would have worked within the community and ported the Webform module to D8. Instead, I chose to start a new project with a new approach.

I feel like the Drupal community might be "shoehorning" my new approach into the Webform module and this is going to require me to takeover the Webform module's expectations and issue queue. I know the issue queue can be filtered by version number but there are dozens of old feature requests (and expectations) in the Webform module's issue queue that could become my responsibility.

Needless to say right now, I feel overwhelmed. Still having the YAML Form module move into the Webform module's namespace does feel like the right thing to do.

I definitely do not want to be the sole maintainer of the Webform module. Many more people and organizations need to be get involved in this effort. I think the ownership and maintainership of the Webform module for D8 must fall on more than one person's shoulder.

Before we move the YAML Form module into the Webform module's namespace I feel several things need to occur…

  • I need immediate help managing the YAML Form project and defining a RC roadmap (http://yamlform.io/developers/roadmap/). In the past two weeks, @cilefen (who is busy enough) has been helping me with YAML Form module's issue queue and it has made a real difference.
  • We need to clearly define what will be supported by D8 version of the Webform module. Personally. I do not want to be supporting data analysis within the core code of the form builder module.
  • I need help, specifically with Views, Rules, possibly Field API integration and last but not least documentation. Also, the YAML Form module needs a very thorough code review.
  • Someone or some organization needs to fully take on the migration path.
  • The D7 Webform module may also need a roadmap. For example, the D7 maintainer need to decide if there be 5.x version of Webform for D7.

In summary, I would like stay focused on getting a stable pre RC release of my current code while implementing some additional bells and whistles along the way. I need the Drupal community's help moving the YAML Form module into the Webform module's D8 branch.

Liam Morland’s picture

The D7 Webform module may also need a roadmap. For example, the D7 maintainer need to decide if there be 5.x version of Webform for D7.

The maintainers have discussed this and there will probably not be a 7.x-5.x. We will continue with bug fixes and features that can be integrated without disrupting the stability of 7.x-4.x.

quicksketch’s picture

That is great @jrockowitz that you are open to it! I know it may seem overwhelming taking on the seeming responsibility of so many sites, but it's often good to keep in mind what we promise under the GPL. Developers are doing this as a service of passing on the freedoms we received by using Drupal. And while we feel responsibility, it's important to know that you owe nothing to users who use your software for free. Rather than be overwhelmed by a large user base, it can be a source of affirmation and incredibly useful tool to make better software for everyone (yourself and your clients included).

this is going to require me to takeover the Webform module's expectations and issue queue.

As far as Drupal 8 expectations, by the lack of a D8 port of Webform, this may have already happened. It's a slower process as users start building D8 sites, but eventually the same issues would be requested from YAML Form as those in Webform. Actually, I've seen that many long-standing requests have been solved in YAML Form, such as flagging submissions and administrative notes on submissions.

We still have a fairly strong team working on the Drupal 7 version of Webform. Considering the separate code bases between YAML Form and Webform, I don't think it would make sense to enforce the same requirement of feature-parity that we attempted in the past (e.g. between 6.x-3.x and 7.x-3.x). Rather, just let the D8 and D7 branch each do their own thing, developing at separate rates, with each feature requested attempted separately in each branch. The development of Webform on D7 has been slowed for the past year or so, and although new features are still occasionally added, that doesn't need to affect the 8.x branch. So basically let the D7 team do their thing, and the D8 team do theirs. With interested parties that have both D7 and D8 sites doing what they can to port features between the two.

yamlform could then be webform (perhaps) 8.x-2.x.

As weird as it might be for YAML Form, the version number that would follow historical patterns would be 8.x-5.x, essentially being "version 5" of Webform. Then people won't think that the Drupal 7 version (3.x and 4.x) are in any way newer than Webform for Drupal 8. But if a 2.x is preferable, that's fine too. It's not uncommon for modules reset back to 1.x in between major versions.

fenstrat’s picture

Fantastic to see consensus coming about here.

Addressing @jrockowitz points:

  1. I can help by cleaning out the Webform 8.x issue queue and once that is done with moving any YAML form issues across.
  2. Moving the module to Webform places no obligations on you or anyone else to build feature X, Y or Z. Just as @quicksketch said, ultimately you *owe* nothing to your users. If someone wants data analysis then they can contribute it. Also, requiring test for all new functionality should help a great deal for maintainability (something Webform 7.x is largely lacking).
  3. Integration with other modules, code review and documentation are all things that can happen moving forward.
  4. As @DanChadwick stated the Webform D6 to D7 upgrade path is solid. As such migration from Webform D7 should be the focus. Given D7 still has a decent life time ahead of it this doesn't seem like such a pressing issue right this moment.
  5. Consensus seems to have formed that Webform 7.x-4.x will be the final D7 branch.

In terms of branches I'd agree with @quicksketch that 8.x-5.x would make sense. Tough so does resetting to 8.x-1.x.

@jrockowitz if you're good with things I'll go ahead and start cleaning out the Webform 8.x issue queue.

Liam Morland’s picture

I think 8.x-5.x makes sense. The existing D8 branch is 8.x-4.x, so 8.x-2.x doesn't make sense to me. If it's a reset, it's 8.x-1.x, if not, 8.x-5.x.

jrockowitz’s picture

I think a complete reset of the Webform 8.x version number to 8.x-1.x makes absolute sense to me, it clearly indicates that there are significant differences between the 7.x and 8.x branches of the Webform module.

I agree with @quicksketch's summary of the GPL and general expectations. I am very comfortable architecting and maintaining a large code base. I am not as comfortable maintaining a large issue queue and "wrangling cats". Simply put, I am better developer than I am project manager. Realistically, to finish this project, I am probably going to have to stop supporting all my other contrib modules for the foreseeable future, which is fine. Still, some developers and organizations need to step up and start helping me with this project.

In the meantime, the YAML Form module's move to the Webform module can proceed gradually. Personally, I hoped to get an RC out the door by Christmas, which would be the 1 year anniversary of the YAML Form module's first commit. Now, maybe the Dev 25th deadline will be code freeze day for the YAML Form module.

There are one or two showstopping issues in the YAML Form module's issue that need to be addressed by me ASAP. Specifically, config translation support is "broken", and the CKEditor integration needs reworking.

I will start creating some of the needed tickets in my issue queue and review my current roadmap.

@fenstrat I think the Webform module and YAML Form module need to first document the "plan" before cleaning out and/or moving any tickets and documentation. I am also curious to know if a D.O webmaster has the ability to bulk transfer tickets from one project to another.

kclarkson’s picture

@jrockowitz,

You are a champion sir!

I have loved YAML forms and your commitment to adding features from day one.

I know this is a scary / huge undertaken but I know you and other community members will step up. I also think if you (we) were to reach out to the larger drupal shops and ask them for support you could get a lot more people involved.

While I am mostly a front-end guy, I can still help with testing patches, feature requests, help with documenation and present at camps about the module etc..

this is the best thing for the community!

KUDOS

Liam Morland’s picture

One problem with resetting to 8.x-1.x is that there is already a 8.x-4.x branch with a partial port.

izmeez’s picture

Coming late to the party, I'm not convinced of the advantages of using the webform name space.

In fact I think the best thing going for drupal 8+ and the yamlform name space is it is a good example of the use of YAML not to mention the significant differences between webform and yamlform.

It also maintains the clear distinction of the significant change for developers and clients going from webform to yamlform.

andypost’s picture

I think better to name it Forms as supposed to migrate parts of it into core experimantal module

fenstrat’s picture

@jrockowitz Once discussion finalises here I'll create a planning issue to track the steps in the move.

@Liam Morland I'd planned to empty out the Webform 8.x-4.x branch, it's partial port is at a dead end. Hopefully we can get a d.o maintainer to then delete the -dev release node and the branch. As suggested by @jrockowitz 8.x-1.x makes sense as the branch where YAML Form will move to.

@izmeez It seems we have consensus for the move, additionally I think the advantages outweigh the disadvantages.

@andypost My understanding of those issues you added is that the core Contact module may look to use the Form namespace. Core Contact and Contact Storage (contrib) modules take quite different approaches to form building (using Core's entity/field API). Improved/merged versions of those modules could make it into core, potentially as an experimental Form module. I'm not sure YAML Form -> Webform could take this route?

japerry’s picture

Great to hear that YAML Form could be moving over to webform. +1!

In response to versions -- typically in the modules I've maintained (panels, ctools, etc) we bump the version number if the API changes. A good example is the ctools project, which had an 8.x-2.x branch as part of the VDO initative, but it ended up going nowhere. With the re-write, we released it as 8.x-3.x. (coming from 7.x-1.x).

I'd highly discourage using 8.x-1.x for the branch. While it is a re-write, it is not the first iteration of the webform-like module. Much like Omega is on version 5 (and had... 4 re-writes?), its better to increment the version to help those who aren't as aware, what the most recent version is. I'd also recommend against using 4.x, not only because of the dead-end code, but because 4.x can imply a direct port/upgrade path from Drupal 7. higher versions, like 8.x-5.x would indicate that this is the newest maintained version. And heck, if the D7 maintainers want to backport the features in 5.x, they could make a 7.x-5.x branch if they wanted.
There might be some build issues as well if you go back to 8.x-1.x. (not entirely sure, but sub versions don't deal well with going down in numbers)..

fenstrat’s picture

@japerry Thanks, all compelling points for 8.x-5.x.

jrockowitz’s picture

Webform 8.x-5.x is starting to make more sense, especially if D.O does not easily support version resets.

DanChadwick’s picture

If the D7 branch needs a new version, what would it be?

Maybe yamlform -> webform-8.x-10.x, leaving room for future divergent D7 branches? Don't see much harm.

I feel like I'm renumbering statements in BASIC circa 1975. :)

fenstrat’s picture

10 probably seems a bit over the top doesn't it? 8.x-6.x would allow a future 7.x-5.x branch, and given at this point there seems like there's no plans for 7.x-5.x this should cover things for the future.

Would be great to hear from @andypost or others Re the core Form namespace future.

jrockowitz’s picture

I am starting to feel that just going with using 8.x-5.x gives the larger Drupal community a sense of continuity, which is a good thing. Even if there is a 7.x-5.x version of the Webform module, no one is going to expect it to be a backport of the 8.x-5.x code.

I just updated the YAML Form's module roadmap (http://yamlform.io/developers/roadmap/) and I think as long as the community provides a decent migration path from D6 and D7 most non-technical users won't realize that the 5.x version is a completely new code base, which I think is a good thing.

If we asked a non-technical Drupal site builder or site owner, what should the next version of the Webform module be, they would most likely say "8.x-5.x".

Liam Morland’s picture

I agree. We don't need to delete the 8.x-4.x branch; it's harmless to leave it there.

jrockowitz’s picture

Status: Needs work » Needs review

So can we make it official that YAML Form 8.x-1.x will become Webform 8.x-5.x. If yes, we can probably close this ticket and I will start creating some follow-up tickets, including a roadmap and moving plan.

Liam Morland’s picture

Sounds good to me. It is possible to merge git repositories, so YAML form can be added to the Webform repo without losing its commit history.

jrockowitz’s picture

I am not too worried about the commit history especially because I am going to have rename so many files. I want to try to get the YAML Form module in a stable enough state before the move so that commit history won't be as important.

Still is it is really nice to know it is possible to preserve the commit history and I will note this in my moving plan.

lomale@bluewin.ch’s picture

what ever happens in the back of drupal. As a non developer. "YAML scares off non developers" is quite true, although if one will work with this super great module, specially the support there is already. YAML indicates that you have to learn about YAML. Thats what I did and it was useful. It helps a lot to be efficient. The word builder is really important too because.
then we have
YAML how it works, what ist the background
Form for what it is
Builder and what it does
sounds logic to me.
even if it would replace any other form module.
it could even be
YAML Form Builder Module

heddn’s picture

Status: Needs review » Reviewed & tested by the community
Related issues: +#2827847: Rename YAML Form 8.x-1.x to Webform 8.x-5.x

Considering #2827847: Rename YAML Form 8.x-1.x to Webform 8.x-5.x is opened, moving this to RTBC.

quicksketch’s picture

I am starting to feel that just going with using 8.x-5.x gives the larger Drupal community a sense of continuity, which is a good thing. Even if there is a 7.x-5.x version of the Webform module, no one is going to expect it to be a backport of the 8.x-5.x code.

+1

A Webform 7.x-5.x is pretty unlikely in any case. We still have 1/3 of all our sites running 7.x-3.x, making another major version in D7 would cause more maintenance headache that I don't think anyone is willing manage.

izmeez’s picture

@quicksketch

We still have 1/3 of all our sites running 7.x-3.x

Actually pretty good if 2/3 are already on 7.x-4.x through transition or migration from D6.

jrockowitz’s picture

Status: Reviewed & tested by the community » Needs review

This ticket has the most followers and the friendliest discussion, so I think we should just keep this ticket open until the renaming/moving of the YAML Form module to the Webform module is completed. Still any specific discussions should be spun-off into existing or new tickets.

So, I have just released beta24 of the YAML Form module which contains a YAML Form to Webform module. This submodule includes Drush commands that convert the currently installed YAML Form module into the Webform module (see drush yamlform-to-webform-convert) and migrates all existing YAML Form configuration and submission data to the new Webform module (see drush yamlform-to-webform-migrate). Please see the YAML Form to Webform module's README.md file for more information.

Writing the drush yamlform-to-webform-convert command will 'hopefully' allow me to continue to support the YAML Form for a few weeks, while everyone moves to the Webform. Basically, I am going to fix issues and bugs in the YAML Form module, run the drush yamlform-to-webform-convert command, and then push the updated code to the Webform 8.x-5.x.

So the next step would be #2830992: Create the Webform-8.x-5.x branch and grant @jrockowitz maintainer access. I will then push up the new Webform 8.x-5.x module and setup a dev release. I am not going to tag any Webform beta releases until beta25 or 26 of the YAML Form module where we can start prompting site administrators, via the Status report, to move to Webform-8.x-5.x.

My hope is to tag a beta1 release of the Webform 8.x-5.x module and deprecate the YAML Form module by Christmas morning (which is the 1 year anniversary of the YAML Form module)

jrockowitz’s picture

Status: Needs review » Fixed

So the YAML Form module has been moved the Webform module. I am still dealing with some migration issues in the YAML Form module. Otherwise all development on the YAML Form module has stopped.

It is time to close the YAML Form chapter and (re)start on the Webform chapter of this story.

I would like to thank everyone for their support and feedback. I look forward to seeing you in the Webform module's issue queue and at DrupalCon.

cilefen’s picture

@rockowitz You've done great work on all this.

jrockowitz’s picture

@cilefen I am looking forward to meeting you at Drupal Camp NJ. I am also working on getting a "Webform for Drupal 8" session into the program.

lomale@bluewin.ch’s picture

Version: 8.x-1.x-dev » 8.x-1.0-beta29
Issue tags: +Thanks!

I would like to thank you and everyone for their help, support and whish you all a Happy new Year.
Would like to meet you sometime somewhere.

PS Migration worked fine with me. from beta29 to webform 8.x-5.0-beta4

Jerenus’s picture

Great to see what happens here. @jrockowitz you've done really great job for the YAML form module and the issue queue. Good efficiency and quality is my impression on this module. Thanks for everyone helping on this and looking forward to the great Webform 8.x-5.0.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.